Re: RGBA opaque regions

[Nathaniel Smith <njs pobox com>]

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?
  -- If the compositing manager and window manager are separate
(arguable whether we want to support that, but that's the model that
the specs currently assume), then how does the CM get this hint into
the WM-managed _NET_SUPPORTED hint?
  -- Apparently the *main* effect of this hint would actually be to
enable RGBA in clients (its possible speed optimizations are fine, but
that change in functionality seems *much* more significant to me). Why
this hint for that? Wouldn't it make more sense to just check for the
presence of a compositing manager (_NET_WM_CM_Sn, where n is the
current screen)? Or if that is inadequate somehow, then a more
specific hint that addresses the specific inadequacy?

-- Nathaniel