[PATCH xserver] composite: Inhibit window background paint with manual subwindow redirection

[Owen Taylor]

On Mon, 2011-07-25 at 20:36 +0200, Marko Macek wrote:

> Sometime in the previous decade I sent patches to Mozilla to always set window background 
> to None (mozilla bug 28003). Hopefully none of it got lost since then.

Mozilla has used background none as long as I can remember. I guess
since your patches... Without a compositor, there are tradeoffs -
background none makes some operations look better, but causes:

 A) Trailing when another window is dragged over a window
 B) Very confusing behavior for the user when the app is
    not responsive - using, for example, alt-tab to switch to an
    application would leave the previous app and the alt-tab popup
    visible.

As long as you can do an at all decent job of predicting the background
color that will be painted (and you can in most applications), I've
always though that those downsides outweigh any advantages for
background None.

With a compositor, these considerations don't really come into play and
there's not much point in pre-painting the backgrounds.

> It makes sense as not only it prevents blinking, it was also visibly faster at the time
> (probably still is). And opaque move/resize is much better.

Really would not expect any noticeable speed difference for a few solid
color fills. (Even a decade ago, but especially today.)

> IMO, this mechanism should be used by all X apps, because the only downside 
> is that background is not painted when app is blocking. The GTK+ mechanism 
> of switching backgrounds seems of little use to me (?).

It might make sense for a toolkit to always use background None in the
composited case.

- Owen