Re: Avoiding flickering

[Owen Taylor <otaylor redhat com>]

Ivan Popivanov <popivan@gmx.net> writes:

> Hi,
> 
> In one of my previous messages, I have mentioned that trying to avoid
> flickering using general approach may lead to other disatvantages. Now I
> am going to discuss this topic further. If gdk drawing is done using
> double buffering, i.e. back pixmaps, the applications will be redrawen
> fine, but the memory usage to achieving this is unfoundedly large.
> 
> One of the most disappointing "features" in gdk is the flickering on the
> main window resize. 

All that work we did to achieve that feature, just wasted! ;-)

> The reason for that flickering is very simple - the
> main window is redrawen before all of the other widgets. Do we need
> double buffering to avoid that kind of flickering? Definitely NO! 

Definitely YES. Setting the bit gravity for the window to something
other than ForgetGravity helps, but does _not_ remove the flicker,
because we clearly need to draw the background before we draw the
text, and that means a momentary flicker. GTK+-1.4 will use a 
bit-gravity of NorthWest to reduce flicker, but will _also_ have the
option of backing store to eliminate flicker.

> The problem is in gdk - it is very "kind" and on every window
> creation sets the background_pixel to some value. In this case, on
> every window redraw (resize generates a redraw), X window server
> fills the window area with the background_pixel color! 

The background pixel only affects what happens on exposes. What
you are noticing is the effect of bit gravity. 

> So, if the background pixel is undefined the X server WILL not
> perform any fill of the window area. In case, your main window
> client area is entirely occupied by another widget (the most common
> case), it will be redrawed without any flickering, because the only
> performed drawing is done in your "gtk_widget_draw" handler!
> 
> So, my proposal is leave the background_pixel and eventually
> background_pixmap members undefined by default.

I have no intention of doing this in general - the visual effects of
doing this (windows have bits of whatever is behind them until they
handle the exposes) can be annoying tend to destroy the illusion of 
overlapping windows. (Have you ever tried flipping virtual desktops
while Adobe Acroread is rendering? You'll notice you'll get the outside
portions, but the inside show the contents of the last desktop until
Acroread comes back from render land. Not something I want to 
have happen in GTK+ programs.). 

There may, however, be cases where setting a background pixmap of none
is useful - for instance, setting a background pixmap of none while
scrolling can reduce flashing.

Regards,
                                        Owen