Re: Merging spif-2 branch

[Havoc Pennington <hp redhat com>]

Hi,

Here's a lesson I think we should take seriously: before we went
all-Unicode, non-European languages were _always_ completely broken.
_Always_. Even though tons of people were trying to keep up by fixing
the bugs, too many people were writing new code that was only tested in
Latin-1. The codepath for CJK was completely different and huge, and app
authors _never_ tested new code with it.

Now with UTF-8, everyone feels the same pain. This got all the multibyte
codepaths fixed in a hurry, and is leading to the current round of Pango
optimization for example.

Back in the day in Red Hat Linux, the number of CJK-specific bugs was
probably hundreds of serious ones and thousands of minor ones.

There's a similar danger with a11y. If we create a huge a11y-only
codepath, people will break it _daily_. There's no way to keep up with
that.

I realize the a11y-only codepath is inherently kind of huge, but to the
extent we can keep it smaller it definitely is in the interests of
everyone...

On Thu, 2005-12-15 at 11:22 +0000, Bill Haneman wrote:
> 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).

If you look at OS X and all its effects, it's pretty far beyond just
alpha blending. If you turned off what would be done by a CM on Linux I
think the result would be near-unusable. I don't expect the Linux
desktop to be any different once the CM is widely deployed and people
start using it in the desktop and apps. You're not going to be able to
police and shut down all this stuff for the universe of apps.

So in practice you'll need a few full-time people sitting there testing
with the CM disabled, a mode nobody but a11y users will be running, and
trying to fix the issues. You'll always be a release behind even if you
get the people to sit there fixing. Or the people to maintain another
CM.

My suggestion instead would be to have a11y features in the normal CM.
For example if you need to disable alpha blending in some cases, have
the normal CM have a setting for that (or since I think the CM probably
just blends at the request of apps, have the apps have a setting or
honor a desktop-wide setting). That is way easier than maintaining your
own CM.

The thing is that a CM isn't a trivial thing at all, it has a bunch of
scary details that seem to require Deep X Knowledge, and those details
will be evolving a lot over time probably. If a11y is a mode of the
default CM, the a11y team can maintain that mode instead of the nuts and
bolts of just making the CM work at all.

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

This doesn't mean you need a custom CM though. Say we go Soeren's route
and have a separate CM process that maintains a scene graph. For the
magnifier, we should just be able to insert an object in the scene graph
that (all within the CM) magnifies another part of the scene graph. I
think the Java 3D scene graph thing and Piccolo (two scene graph libs)
both have this feature already in fact.

> >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?

As I said, because nobody will ever run or test with your CM. It'll be
out of sync with the X stuff probably, out of sync with GTK, out of sync
with metacity; and app authors will be writing animations and alpha
blends and all kinds of crazy stuff, and they will be testing with the
default CM/WM setup and that's it. Someone will have to run along behind
them sweeping up, and in effect they won't keep up and a11y mode will
always be buggy.

>   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

What I'm saying is that I think you guys are in a bad spot until/unless
there's more API for communication with the compositing manager.

>  this is the way we agreed that we needed 
> to proceed.

For now when the CM doesn't really do anything, I agree you could just
do your own CM. Replacing the awesome capabilities of xcompmgr isn't too
challenging. But as soon as people start really using the CM I would
make dire predictions for the success of a separate a11y-specific CM
approach.

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

I don't agree with Keith I guess, it doesn't make sense to me. To make a
CM worth doing at all it should essentially be an extension of the
current drawing APIs to a much more powerful set of operations, and apps
need to be able to rely on those. That means a pretty complex CM and it
means that apps will come to rely on the CM existing in order to work.
Maintaining an alternate CM would be like having special X drivers or a
special X server for a11y.

Just seems to set a11y up to fail.

The approach that makes sense to me is that the CM or WM just has a
magnifier built into it, and settings to disable whatever alpha needs
disabling. Or if the CM is someday flexible enough, the magnifier could
be another client of it. But having the magnifier in the CM process
doesn't seem crazy to me in the meantime.

I don't think this will bite you for 2-4 years since the CM won't be
widely used very quickly, but if investing a lot of energy in a
magnifier, it might be worth getting right the first time, at least in
rough outline.

Havoc