Re: [gtk-list] Re: Code escape: Gzilla 0.01
- From: Raph Levien <raph acm org>
- To: Owen Taylor <owt1 cornell edu>
- cc: gtk-list redhat com
- Subject: Re: [gtk-list] Re: Code escape: Gzilla 0.01
- Date: Thu, 15 May 1997 20:42:40 -0700 (PDT)
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 188.8.131.52...
> 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
> 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...
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
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 :-)
] [Thread Prev