Re: Merging spif-2 branch

Havoc Pennington wrote:

On Wed, 2005-12-14 at 09:08 +0000, Bill Haneman wrote:
PLEASE make this runtime configurable before committing to CVS! This is important to us.

But step back and figure out how it's configurable. Is it a metacity
setting or some kind of session-global "eye candy level" or even an X
I don't care, as long as it can be turned off and the desktop will still work properly (as long as there's some other compositing manager doing the alpha blending where necessary). IN fact use of alpha blending by apps is a bit of an accessibility nightmare in itself, so we want to be able to clearly distinguish between eye-candy, which we can and should be able to live without, and uses of alpha blending which are required for proper use of applications. It's very easy to dis-improve accessibility with these sorts of features, if you consider for instance the need for high-contrast, and/or flattening of the screen for blind users, who will need to see a 1D or 2D representation of the screen. Of course if the magnifier is the compositing manager, it gets to see the alpha/compositing requests and may choose to act on them differently from the "standard" compositor, in order to improve the experience of a user with vision problems.

I do wish you would show a little faith in the a11y and magnification teams.

I'd like to know why this magnifier problem is the case, though.
For one thing, it has to do with performance. We have serious performance issues with the current model in which every expose requires XCopyArea and every update/damage requires client-side gdkpixpuf scaling (given that the compositing manager has to grab these pixels and redisplay them as well). I admit to not knowing the internal details of the compositing manager's connection to the physical framebuffer and virtual window contents but it seem to me that relationship needs to be optimized for the compositing manager's performance, so we need to take advantage of that, not add extra round trips. We are at a rather severe disadvantage performance-wise to Windoze which normally does this by replacing or hacking into device drivers, and thus can provide hardware-accelerated magnification/scrolling, and COMPOSITE is one of the things which has been offered up as a partial solution.

certainly would foresee a future (in a few years granted) where
compositing is effectively mandatory, if only because nobody ever runs
or tests without it. We need a better plan than requiring the magnifier
to be the CM, it's not long-term viable, it's a bad setup.
Why? This is what Keith suggested to us in January and previously, when we sat down and discussed the issues. Until/unless COMPOSITE provides more API for communication with the compositing manager, or chaining/multiple compositors, this is the way we agreed that we needed to proceed.

I am in favor of the latter (multiple compositors or some kind of compositor chaining, internal pluggable API, etc.) but Keith seemed to think that was low priority.


It's possible the right plan is that the magnifier is just *in* the
window manager, or closely coordinated with it anyway.


metacity-devel-list mailing list
metacity-devel-list gnome org

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