Re: gdk_window_set_back_pixmap()

On Fri, 2006-10-27 at 07:33 -0500, Matt Hoosier wrote:
> A couple of weeks ago, I asked here whether anybody had a good
> technique to prevent the initial tiling-to-white that happens when a
> GtkWindow first is mapped and exposed.
> One solution that was offered is to install a "realize" signal handler
> which just does this:
>   gdk_window_set_back_pixmap (w->window, NULL, FALSE);
> This causes the contents of the underlying X11 window to be either
> transparent, or a snapshot of the underlying root window

It causes it to not be repainted at all leaves whatever was there before
until the apps draws.

>  [I can't
> entirely tell from the documentation:
> Disregarding which of those two approaches happens, the result is not
> to show the logical conents of the window until it's rendered under
> its own power.  At least visually, the result is much smoother.
> Are there down-sides to this; that is, why does Gtk not use this trick
> by default?

The effects of not having a default repaint to the background color
can be quite confusing (have you ever switched to a desktop with Firefox
on it and been puzzled as a Flash add appeared on top of the previous
desktop, then Firefox redraw?).

This is especially a problem on heavily loaded systems.

Also, the appearance of trails as you drag another window on top
may be worse than the clearing to the background color, as long as the 
background color is a close approximation of the window contents.

In some cases, temporarily unsetting the background then setting
it back can make sense ... GTK+ does this when both mapping a menu
(for the menu) and unmapping a menu (for the underlying window).

It's hard to do this effectively for window manager managed windows,
since you don't know when the window will be mapped.

Compositing managers with good synchronization between the CM and the
toolkit are the real answer here.

						- Owen

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