On Sun, 2009-12-20 at 12:56 -0800, Nathaniel Smith wrote: > On Sun, Dec 20, 2009 at 8:55 AM, Cody Russell <brats...@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 _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list