Re: oustanding gtkwindow.c FIXME
- From: Tim Janik <timj gtk org>
- To: Soeren Sandmann <sandmann daimi au dk>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: oustanding gtkwindow.c FIXME
- Date: Fri, 17 Aug 2001 18:55:32 +0200 (CEST)
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
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
> 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
jup, we always did that, and have to keep the guarantee i mention above.
] [Thread Prev