Re: RGBA opaque regions
- From: Cody Russell <bratsche gnome org>
- To: Nathaniel Smith <njs pobox com>
- Cc: wm-spec-list gnome org
- Subject: Re: RGBA opaque regions
- Date: Fri, 25 Dec 2009 13:27:21 -0600
On Sun, 2009-12-20 at 12:56 -0800, Nathaniel Smith wrote:
>
> 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?
Owen Taylor was the one who suggested I add this hint that he can use
for Metacity and Mutter. I believe he mentioned doing some kind of
measurements, but I don't have any data on that.
> -- 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?
I don't know, but this isn't the first CM hint is it? Since I joined
this mailing list to propose this I think I've already seen another
proposal for a CM hint, so I assume the issue of WM/CM separation isn't
specific to my hint and if someone solves it for one hint then it's
solved for them all.
> -- 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?
The main effect is to enable RGBA *by default*. Right now GTK+ can
obviously support RGBA windows, and it's not a big deal. But Owen said
that when he has experimented with turning *all* windows into RGBA then
he has seen performance issues on Metacity and/or Mutter. I haven't
seen any such issues on Compiz though, possibly because it's a GL
compositor but I don't want to speculate why.
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.
But this only really affects certain compositors as I described above.
GTK+ shouldn't have to make assumptions like "if there is a CM, then
let's support RGBA by default." The existence of this hint should be
able to reassure the toolkit that the CM is able to handle RGBA by
default. In the case of Compiz, perhaps the hint exists for that
purpose but does nothing. In the case of Mutter then it exists and does
some kind of optimization based on the data. Maybe Metacity doesn't
expose the hint at all (since it's not really maintained anymore afaik)
so GTK+ would use RGB windows by default.
/ Cody
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]