Re: oustanding gtkwindow.c FIXME



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 :-)

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.

A widget could turn these flags off if it wanted to handle redraws
itself.  If it turned them off, only the part of a widget that was
uncovered would be invalidated.  The widget would be responsible for
invalidate whatever else was needed.  

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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]