Re: RGBA opaque regions



On Fri, 2009-12-25 at 22:36 -0800, Nathaniel Smith wrote:
> > Being able to only composite specific regions of the window that are
> > known to be opaque (despite being RGBA) is the purpose of this hint.

Sorry, I wrote that incorrectly.  I meant to say something like:
   "... only composite specific regions of the window, excluding the
ones known to be opaque (despite being RGBA)..."

> Wait, now I'm confused -- I thought the hint told the CM that certain
> regions were opaque, not that all un-mentioned regions were fully
> transparent. The former would allow the optimization of not
> compositing regions of other windows that are "behind" the opaque
> region, the latter allows the optimization of not compositing the
> fully transparent parts at all. Which is it?

It does tell the CM that certain regions are opaque.  The region
specifies parts of the window that are known to be completely opaque.
All other parts of the window may have any amount of alpha value, and
those are the parts that the CM should actually composite.  The CM may
opt to *not* composite the parts of the window that are described by the
region.

> If this is what's needed, why aren't you proposing a
> _NET_CM_IS_FAST_NO_REALLY_I_MEAN_IT hint? Does your hint actually
> *fix* the problem with Mutter? 

The hint itself doesn't fix anything.  The hint provides information to
the CM so that it can either use it to optimize compositable regions or
it can ignore it if it doesn't care.  Its existence also provides a
reasonably reliable hint to the toolkit about whether it's safe to use
RGBA by default.  I'm not a Mutter developer and I'm not planning to
implement the optimization in Mutter, I'm a GTK+ developer acting here
on the requirements set by Mutter developers and other GTK+ developers.
They said that in order to enable RGBA by default in GTK+ we need this
hint.



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