After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 579427 - f-spot should be multi-threaded.
f-spot should be multi-threaded.
Status: RESOLVED INVALID
Product: f-spot
Classification: Other
Component: General
0.5.x
Other All
: Normal enhancement
: ---
Assigned To: F-spot maintainers
F-spot maintainers
Depends on:
Blocks:
 
 
Reported: 2009-04-18 16:58 UTC by annex666
Modified: 2009-04-28 19:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Sharpening using 100% of only one core. (641.63 KB, image/png)
2009-04-28 19:40 UTC, annex666
Details

Description annex666 2009-04-18 16:58:17 UTC
Many f-spot operations are CPU-intensive; when performing such tasks the UI becomes unresponsive and screen taring/glitching occurs.

This problem can be solved by adding threading support - at very least to separate the GUI and main working thread, but also the possibility of multiple working threads.

This fix would not only solve the UI problems, but would also allow f-spot to be more responsive on systems with multiple cores (which are practically the norm. these days).

This bug report was opened as the result of a downstream bug (showing an example of the UI bugs): https://bugs.launchpad.net/ubuntu/+source/f-spot/+bug/336334
Comment 1 Maxxer 2009-04-21 19:57:40 UTC
related to bug 502365
Comment 2 Stephane Delcroix 2009-04-28 08:39:10 UTC
f-spot uses threads. a lot.

such enhancement request aren't useful without
1) precise information of what's slow (information lost from the downstream bug), or
2) deep analysis with timing, or
3) patches

Please file more atomic bug report/enhancement request, but as far as I'm concerned, the "should use threads" is solved. closing.
Comment 3 annex666 2009-04-28 19:40:34 UTC
Created attachment 133522 [details]
Sharpening using 100% of only one core.
Comment 4 annex666 2009-04-28 19:44:05 UTC
I've attached the image from the original bug report.  When performing sharpening only one core gets any work which implies that either sharpening is not threaded or that all but one thread are starved and/or not scheduled.

This should be reproducable locally.

Note that I am sharpening a .NEF (Nikon raw format) file.