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 595960 - [performance] thumbnails are slow to generate when zooming
[performance] thumbnails are slow to generate when zooming
Status: RESOLVED FIXED
Product: pitivi
Classification: Other
Component: User interface
Git
Other Linux
: Normal normal
: 0.13.4
Assigned To: Pitivi maintainers
Pitivi maintainers
Depends on:
Blocks:
 
 
Reported: 2009-09-22 14:10 UTC by Jean-François Fortin Tam
Modified: 2010-02-05 23:26 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jean-François Fortin Tam 2009-09-22 14:10:17 UTC
Similar/related to bug #589809, but not quite I think. What I think I have noticed is that, when you change zoom levels, thumbnails and waveforms for each intermediary zoom step continue to generate in the background. The effect of this is that when you have finished zooming and reach the desired zoom level, you have to wait a *long* time for the thumbnails/waveforms to start appearing/generating.

What it looks like (at first sight) is that pitivi is busy working on the thumbnails/waveforms of the zoom levels "between" the initial one and the final one, which is very expensive.

If my assumption is correct, then shouldn't the thumbnail/waveform generation mechanism have a different "queue" for each zoom level, and when you change zoom level, "kill" the previous queue to prioritize the current zoom level? Thus, when you reach the final zoom level, it starts working on generating the thumbnails/waveforms for this zoom level immediately.
Comment 1 Jean-François Fortin Tam 2010-02-05 23:26:27 UTC
Emdash's work in the past few months has made thumbnails quite a lot faster and they do not need to be regenerated when changing zoom levels, which is awesome.