Re: RGBA opaque regions

[Owen Taylor <otaylor redhat com>]

On Sun, 2009-12-20 at 12:56 -0800, Nathaniel Smith wrote:
> On Sun, Dec 20, 2009 at 8:55 AM, Cody Russell <bratsche gnome org> wrote:
> > I would like to re-propose a new hint for the ewmh spec, with the changes
> > that were suggested by Fredrik Höglund.
> > _NET_WM_OPAQUE_REGION
> > As I would like to change gtk+ to be able to support RGBA colormaps by
> > default, we would like some mechanism to allow the compositing manager to be
> > optimized by knowing the regions of the window that are opaque.  Matthias
> > Clasen would like to only enable RGBA-by-default in gtk+ if this proposed
> > hint is available in _NET_SUPPORTED.  The toolkit would store the region as
> > a list of rectangles which represent regions that are known to be opaque.
> > If nobody disagrees, I will try to prepare a patch against the spec and file
> > that.
> 
> I'm afraid I'm still a bit puzzled (apologies if you've already
> explained this somewhere), but:
>   -- Are any compositing managers planning to take advantage of this
> hint? All compositing managers I'm aware of use some sort of
> server-side blit (through GL or XRender) for their compositing anyway,
> and it isn't clear to me that this is actually an optimization or not.
> Do you have some specific use-case or measurements?

No window managers currently use Cody's proposed specification, but the
optimization of not drawing obscured regions is something I've
implemented in Mutter which has proved to be a significant optimization.

And if a toolkit makes every window an ARGB to be able to do client side
decorations with nicely rounded corners, then that optimization is
impossible without some sort of hint like Code is proposing.

It's incorrect to consider a hardware accelerated blit to be infinitely
fast - it's pretty common to have a situation where you have say 8
full-screen 1400x1050 windows stacked on top of each other. To draw that
at 30hz is over a 1GB/sec of reading from texture memory (which might be
over the AGP bus on a limited or older memory machine.) And then
alpha-blending is another 2GB/sec of read/write traffic to the frame
buffer.

So, avoiding alpha-blending every window for every frame makes a huge
difference:

 - On older low-memory video cards where window textures will be forced
   out to AGP
 - On older unified memory system where reading and writing the frame
   buffer will eat into a limited amount of system memory bandwidth.

Even on the highest end machines, people would like to use their memory
bandwidth and GPU cycles in their apps not in the CM, so it's not a bad
optimization, but on the older machines described above it can make the
difference between usable and not usable. Personally speaking that was
the case for my R300/64M VRAM laptop, and that's not a level of hardware
we can afford to write off yet as too old and slow to be interesting.

- Owen