zooming is slow

[Miklós Máté]

Zooming is quite slow and does not follow the zoom slider interactively. The two magnifier glass buttons are better, but it takes almost a second to update the timeline (with a dozen clips on 4 tracks, ``simple'' theme) on a 2.8GHz P4.

Furthermore, the fully-zoomed-out position on the zoom slider should adapt to the length of the project.

[moimael (moimael)]

Maybe we should take a look at clutter instead of using goocanvas.

It's hardware accelerated and can provide a smooth and beautiful experience.

I will try to port track to use clutter.

[Miklós Máté (mtmkls)]

I don't think clutter will improve the situation. Goocanvas uses Cairo, which in turn uses XRender, which is hardware-accelerated by nearly all drivers. Clutter on the other hand uses OpenGL, and no one knows if it works without 3d acceleration. Also see this thread: http://old.nabble.com/clutter-or-goocanvas-for-PiTiVi-td17221802.html

Moreover, scrolling and working with clips are OK, just zooming is slow, thus it might not be Goocanvas' fault.

[Almer S. Tigelaar (almer)]

This problem is two-fold:

1) The slider itself uses a delayed update policy, meaning that the update signal to redraw the goocanvas is emmitted only every now and then while dragging. Changing the policy is easy to do in the UI files.

2) When changing the slider's update policy the redraw (effectively the Render() method in the sequence class) is invoked continuously while dragging which results in some serious flickering.

Fortunately, there is a solution to (2) as well: simply temporarily postponing redraws while the goocanvas is being redrawn. Then allowing a redraw once the goocanvas contents have been rebuild.

I've attached a patch which enables smooth zooming via the zoom scroller.

[Olivier Girard (eolinwen)]

Thanks a lot for your patch.
I switch it for the next milestone, but I 'm not sure if it will be in this one. Crossed fingers.

[Andy Finch (fincha)]

Thanks for the patch, I've committed it to the trunk.