Re: Smooth zooming

[Paul Davis <paul linuxaudiosystems com>]

On Wed, 2008-02-20 at 11:24 -0500, Lindley M French wrote:
> I've asked this question on several Gtk forums on previous occasions, but never got much of a response. As this list seems a bit more active, perhaps my luck will be better here.
> 
> I'm trying to implement a zoomable + scrollable window which remains centered on the same point while it zooms. To this end, I have the following hierarchy:
> 
> vbox
>   scrolled_window
>     draw_area
>   hscale

the short answer is that you can't do this at present.

GTK uses window-system-level level routines to implement the move/scroll
part of this. When you change the adjustment, the window is moved using
(on X11) XMoveWindow. If you do not change the zoom at the same time,
this is exactly what you want - the area of the window that is newly
displayed gets redrawn by a suitably constructed expose event and
everything is good.

However, if you wanted to change the zoom as well what actually happens
is that the window gets low-level moved by the adjustment change, and
the later redraw of the entire window (required by your zoom change)
comes along later. There is nothing in the X API (and hence in the GTK
API) that can stop these two visual effects being completely disjoint
from each other. Sometimes you get lucky - the speed of the X server in
handling the requests and the synchronization with the screen's vertical
redraw timing means that you don't see them as two separate effects. But
most of the time, you (or your users) are not so lucky, and the glitch
is clear.

This at least is my conclusions after deep investigative work trying to
do the same thing as you in the context of the GnomeCanvas.

You need a new kind of widget that never ever uses lowlevel window moves
as a way to accomplish scrolling, or rather, uses them only when the
widget users makes it clear that no accompanying zoom is scheduled. That
is, when doing "scroll+zoom", it would skip the lowlevel window move and
just lead to a redraw of the entire window. I do not know of any GTK
widgets that can trivially be adapted for this purpose. Most of those
involved in scrolling use the position of the scroll adjustment to
indicate the amount by the which the larger window has been offset using
lowlevel window motion. The moment you skip a lowlevel window move as
part of a scroll is the moment that these widgets completely lose track
of what is being displayed.

I currently consider this one of the most egregious design flaws in GTK,
although there are no too many of these so thats not saying much :)

--p