Re: RE: Scrolling a drawing area

["Dov Grobgeld" <dov grobgeld gmail com>]

For what it is worth, the DovImageViewer (which is part of giv), does a single redraw based on a call to:

gint  dov_image_viewer_zoom_around_fixed_point   (DovImageViewer * self,
                    double new_scale_x,
                    double new_scale_y,
                    double old_x,
                    double old_y,
                    double new_x,
                    double new_y);

It will transfer the old widget coordinate (old_x,old_y) to (new_x,new_y) while zooming in (or out) to (new_scale_x, new_scale_y). If adjustments have been attached to the widget, then these are updated as well.

Since the entire GdkPixbuf is prepared before it is being exposed in the window through a call to gdk_draw_pixbuf() the result is quite smooth. (At this point the user of the widget can connect to a signal and add annotations to the pixbuf, before it is being shipped to the screen.)

Am I still missing something? I agree it wasn't easy to get coordinate systems correct in the widget implementation, but there is nothing intrinsic in gtk that hinders it.

Btw, please ignore the old GtkImageViewer widget at my web site. It is obsolete.

Cheers,
Dov

2008/5/19 Paul Davis <paul linuxaudiosystems com>:

On Mon, 2008-05-19 at 11:39 +0300, Dov Grobgeld wrote:
>
>
> 2008/5/11 Lindley M French <lfrench1 gmu edu>:
>         [stuff deleted]
>
>         Be warned: Due to the way resizing works in GTK+, it's
>         impossible to do "smooth zooming" where your scrolled window
>         remains focused on the same part of the image as you zoom. You
>         can approximate it, but the zoom itself will be jerky. I
>         haven't found any way around this.
>
> Not sure what you mean by this. I'm doing zoom-in in my image viewer
> giv (http://giv.sf.net/giv) through the GtkImageViewer widget (which
> is currently bundled in giv under the name DovImageViewer). The
> ImageViewer widget takes care to zoom in so that the position of the
> mouse is centered in the zoomed in image... But perhaps you meant
> something else?

the problem is this ... when a GtkWidget ends up using XMoveWindow to
reset the "origin" for the visible part of itself, and then follows up
with a redraw of the entire window contents, these two things happen
asynchronously. The XServer takes care of the window move, then the
client redraws. Many (all?) of the existing GtkWidgets that one might
use for this sort of thing all gdk_move_window() to do the origin move,
and are thus subject to this problem.

What is actually needed for this purpose is just a widget which
differentiates between:

      * scroll
      * zoom with constant window origin coordinates
      * zoom with constant non-origin focus

right now, too many of them take the easy way out, and do the third case
as a combination of the first and second. on X Window, this always
results in a double draw of the window.

--p