Re: gdk_window_set_back_pixmap()

["Matt Hoosier" <matt hoosier gmail com>]

Okay, thanks for the info.

--Matt

On 10/27/06, Owen Taylor <otaylor redhat com> wrote:
> 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:
> > http://developer.gnome.org/doc/API/2.0/gdk/gdk-Windows.html#gdk-window-set-back-pixmap].
> > 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