On Fri, Dec 25, 2009 at 11:27 AM, Cody Russell <brats...@gnome.org> wrote: > 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.
I have no standing vis-a-vis the EWMH spec -- I'm not sure if anyone in particular does, for that matter -- but if I were the editor than I would like to see those measurements before enshrining anything in the spec, not just hear rumors about their possible existence :-). >> -- 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. I don't know of any other CM hints in _NET_SUPPORTED, though I could have missed one. >> -- 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. Yes, enabling RGBA "by default" is what I mean. This makes the hint far more than a performance optimization; it will cause (potentially user-visible) behavioral changes. > 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. 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? > 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. 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? -- Nathaniel _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list
