Re: oustanding gtkwindow.c FIXME

[Tim Janik <timj gtk org>]

On 15 Aug 2001, Soeren Sandmann wrote:

> Owen Taylor <otaylor redhat com> writes:
> 
> > But the unconditional queue-redraw-on-the-whole-window we do
> > when we receive a configure event is causing us to redraw
> > quite a bit more than necessary -- with speed penalties when
> > we double-buffer and flash penalties when we don't.
> > 
> > I'd still like to investigate getting rid of this.i 
> 
> 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).

> 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
is not a viable aproach for speed-ups.
there're lots of other areas where we can improve speed significantly though.

> For example, the Canvas should not have to have its entire gdk-window
> invalidated just because someone resized it.

that depends, imagine a canvas having an item that's always to be centered.
in any case, the canvas could do better with caching pre-rendered regions,
since currently it not only redraws but also rerenders every exposed
rectangle, which causes quite a bit of extra work being done.
(on the other hand, caching means full double-buffering of the visible
canvas area, so it'd have a considerable memory impact on the X server side).

---
ciaoTJ