Re: [gtk-list] Re: Code escape: Gzilla 0.01

[Raph Levien <raph acm org>]

On 15 May 1997, Owen Taylor wrote:

> 
> Since www.levien.com seems unavailable right now, I haven't been able
> to take a look at Gzilla yet (...impatience...), but I'll give some
> (unresearched) thoughts on the resize problem anyway.

Perhaps DNS problems? www.levien.com is 207.105.6.77...

> I don't think it's the server that's doing the blanking - a quick
> test I did was to try stopping a program and then resizing it's
> window - and no such blanking occurred. 

Here's what I think is happening: the program you were running had all 
the content in child windows. When you did the resize, it blanked the 
topmost window, but left all the child windows unscathed.

I did the same test as you on both gzilla (which has the structure I 
described above -- nothing in the topmost window), and xink (which has 
_everything_ in the topmost window). The server graciously blanked xink's 
window when I resized it while xink was suspended.

> The problem, I think lies with GTK_NO_WINDOW widgets. Because they
> don't have an underlying X window, gtk has to deal by hand with
> trying cleaning up after them. For instance, any time a GTK_NO_WINDOW
> widget is resized, the area underneath it is cleared 
> (see gtk_widget_size_allocate). (Actually, as evinced by various
> label display problems, gtk may not be doing _enough_ clearing.)

I checked this out pretty thoroughly. For one, I tried gtk_page as both a 
no_window widget and one with its own window (there's a switch in the 
code). It blanked in both cases. Eventually, gtk_page will have to have 
its own window, so that it can handle clickable links.

I also tried removing the call to gdk_window_move_resize, and that did 
stop the blanking. This strongly suggests that it wasn't gtk. Checking 
the source code, gdk_window_move_resize is just a wrapper around 
XMoveResizeWindow.

> The solution may be to separate out two different types of
> GTK_NO_WINDOW widgets: those that actually draw things (label, pixmap,
> etc.) and those that don't (vbox, alignment, etc.)  Clearing on
> move/resize shouldn't be necessary for the second class, so perhaps
> things could be fixed up either by simply restoring a X window to the
> first class or by adding another flag to indicate that a widget needs
> its old area to be cleared on move/resize.
> 
> Just some thoughts...
>                                         Owen

I just did some further experimenting, and think I have found my answer: 
simply create the window with a ridiculously large size, then never 
change it. I'd still do gtk+ size negotiation (so the viewport will 
continue to display it correctly), but just skip the gdk window resize.

Of course, I will have to manage my own repaints, because now I can't 
just wait for an expose event, but that's what I wanted anyway. Another 
drawback is that, unless there's a good way for the repaint code in 
gtk_page to find out its viewable area, is that I'd have to repaint the 
entire window -- one advantage of using window resize is that it would 
generate an expose event that was limited to the window's actual viewable 
size.

One hack I can think of is to simply use the union of all past expose 
events. Since most new rendering will happen off the bottom of the 
screen, this should work well in practice. I can live with it.

The one major problem I can think of is that X limits the window size to
32767. Oh well. Nobody ever reads to the end of pages that big anyway :-)

Raph