Re: [gtk-list] GraphicsExpose (was Re: About the About Box)

[Raph Levien <raph acm org>]

On Sun, 14 Dec 1997, Owen Taylor wrote:

[excellent explanation of GraphicsExpose elided]
> 
> As far as I know, only two pieces of code use gdk_draw_pixmap 
> window-to-window copying for scrolling - the text widget and
> scrolling in the GIMP. The code in the GIMP doesn't work properly
> (probably because of the above mentioned timing issues) - try
> scrolling a window with button-two that is partially obscured.
> The Text widget doesn't seem to show this problem, but possibly
> only because it is faster at doing the redrawing.

The text widget is careful not to copy from any region offscreen. If you 
look at scroll_up (for example) in gtktext.c, you'll see that scrolling 
is accomplished by both a call to gdk_draw_pixmap (which wraps XCopyArea 
in this case) and expose_text, which draws the text in the uncovered area.

Nonetheless, the gtk_text widget does deal with GraphicsExpose events 
when scrolling a partially obscured window. Apparently, the 
GraphicsExpose events are translated into plain Gdk expose events, and 
the handling is correct.

I've also noticed the Gimp image area scrolling bug - it's especially a 
problem in conjunction with fvwm95's task bar at the bottom of the 
screen. I haven't looked into it at all, though.

> So, for starters, I would like to make no graphics expose events
> the default for GDK created GC's. 

I'm not quite sure I understand the proposal. How are you going to detect 
the case when XCopyArea is used to scroll inside a partially obscured 
window? Unless I totally misunderstand, enabling graphics expose is the 
only way to do this.

> I'm not sure what to do about the translation of GraphicsExpose =>
> Expose. I'll probably have to fix the code in the GIMP to figure
> out what the right course is.
> 
> Comments? Objections? 

Currently, Gzw (and thus Gzilla) handles scrolling by moving the 
underlying X window, pretty much the same as gtk_scrolled_window, except 
with some stuff to handle >32kpixel scrollable regions. Thus, the stuff 
scrolled in is handled by a vanilla expose event. This works ok, but you 
do get the round-trip latency of waiting for the expose event, which is 
visually noticeable. It's especially noticeable when scrolling very 
quickly and/or on a highly loaded machine. I'd like to add an alternate 
mode that works the same as gtk_text. On the other hand, the gtk_text 
method works very poorly when there are embedded non-NO_WINDOW widgets. 
In any case, I'm certainly interested to find out how this is resolved.

Raph