Re: Merging spif-2 branch

[Bill Haneman <Bill Haneman Sun COM>]

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
> setting.
>  
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.

> I
> 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.

Bill

> It's possible the right plan is that the magnifier is just *in* the
> window manager, or closely coordinated with it anyway.
>
> Havoc
>
>
> _______________________________________________
> metacity-devel-list mailing list
> metacity-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/metacity-devel-list
>