Re: oustanding gtkwindow.c FIXME

[Tim Janik <timj gtk org>]

On 16 Aug 2001, Soeren Sandmann wrote:

> Tim Janik <timj gtk org> writes:
> 
> > > It would certainly be nice if it was possible, but the things I have
> > > tried have always resulted in weird bugs and areas that should be
> > > redrawn, but wasn't.  Of course, this is most likely because I don't
> > > know what I am doing :-)
> > 
> > there's no extraneous resizing/redrawing being done in our configure_event
> > handler, it just handles resizes that were previously deferred because
> > we knew we're about to receive a configure event.
> > 
> > extra work redrawing (not resizing) work is just being done at the point
> > where we're deferring the resize (and that's the original FIXME).
> > if you suspect this to cause noticable lag on your machine, you can
> > check that with calling gtk_container_set_resize_mode (window,
> > GTK_RESIZE_IMMEDIATE) on your toplevel window (this will avoid
> > deferring the resize, but also, if the window manager's configure
> > event did change our window size, cause an extra flicker).
> 
> A configure event is handled (essentailly) by queuing a resize, which
> takes effect in the idle loop.  On my machine, the queueing of a

only if:
a) the configure event changed our window size
b) the configure event is sent to us in response to a prior
   gdk_window_resize() request, where we deferred actuall widget
   tree resizing, because we knew we'd get a configure event now.
   
> resize takes a few milliseconds - not a big deal, and if the time

certainly not, there's no point in measuring resize _queuing_ as that
is just putting the window into the resize_container list.

> spent on size_allocate and redrawing is reduced, so is the number of
> queued up configures, because the user will have less time to generate
> them.
> 
> Did you see the data I posted a few days ago? According to them, size
> allocation of the testgtk toplevel window takes around a third of
> second and redrawing takes up to 7/10 second.  The time to queue up
> resizes from configure events is not important compared to that.

what i meant is the lag introduced by not resizing the widget tree in
gtk_window_move_resize() right away when we issued gdk_window_resize(),
but waiting for the window managers response in form of a configure event.
this involves a gtkapp->xserver->windowmanager->xserver->gtkapp roundtrip
which might introduce noticable lag.

> > > One possible solution, maybe for 2.2, is to add flags H_REDRAW and
> > > V_REDRAW, like on Windows, which, for compatibility, would be set by
> > > default.  When the H_REDRAW flag is set, GTK+ guarantees that the
> > > widget is completely redrawn when its horizontal allocation changes.
> > > Similar for the V_REDRAW.
> > 
> > if a widget expanded in one direction, it needs to be completely new size
> > allocated (and also its chilren) and therefore redrawn, so this
> 
> Why does "size allocate" imply "complete redraw"?  If a widget unsets

size_allocate for size!=oldsize guarantees a complete redraw, since most
widgets have to change everything if that happens.

> these flags, it would itself be responsible for invalidating those
> areas that needed to.
> 
> > is not a viable aproach for speed-ups.
> > there're lots of other areas where we can improve speed significantly though.
> 
> In fact, the way I read gtk_widget_size_allocate(), it *tries* to
> avoid redrawing by doing
> 
>   [...]
>   else if (widget->allocation.width != real_allocation.width ||
> 	   widget->allocation.height != real_allocation.height)
>     {
>       needs_draw = TRUE;
>     }
> 
>   [...]
> 
>   if (needs_draw)
>     {
>       gtk_widget_queue_draw (widget);
>       if (widget->parent && GTK_CONTAINER (widget->parent)->reallocate_redraws)
> 	gtk_widget_queue_draw (widget->parent);
>     }
> 
> This is bogus, though, because
> 
>   a) queue_resize() already queued a complete redraw of everything from
>      the resize_container down.

nope, queue_resize() only invalidated the old window size. if the
new size is bigger than the old size, gtk_widget_queue_draw() takes care
of invalidating the new regions as well.

>   b) queue_draw() clears a widget's window and all subwindows - which
>      means that every sub-widget is cleared whether it's resized or
>      not.

jup, we always did that, and have to keep the guarantee i mention above.

---
ciaoTJ