Hi Carlos, >>> ... >> I would like to suggest more study of the Compiz option before making >> the decision to work with Metacity instead. While today it seems no >> desktop UNIX distro is prepared to replace Metacity with Compiz, it does >> appear that many (most? all?) are looking to have it as a user-available >> option. I continue to believe that (a) Metacity is largely in >> maintenance mode with new sexy development happening in Compiz; (b) we >> can do a lot more, and do it more naturally and easily in Compiz; and >> (c) if we do a great job with magnification in Compiz, we will be able >> to help move folks over to Compiz, either as a default user-choosable >> option, as a trivially user-installable option, or even as the eventual >> default window manager. >> >> This is clearly something we need to socialize with the desktop folks, >> the Compiz folks, to determine how much of a..c above are in fact the >> case. But I would especially hate it to be the case that we do a lot of >> work to make Metacity great for magnification, only to see it slowly >> fade away (or have to argue for folks to keep it when their >> desire/tendency is to move to the new sexy thing). >> > > This is really a great point to consider. I don't know how is the > metacity compositor development, but I think that we are not getting > much on this and that users will move to the new sexy thing, due the > reaction these things are causing on people. I think that you are > right, the most sane thing to do will probably extend the > accessibility resources on compiz. What you propose to we start to > socialize with destkop and compiz folks? > > If some ATs will communicate throw AT-SPI, like in the examples that > Willie cited, the compositor must support CORBA (something that I > believe that will never be accepted), or re-implement AT-SPI over > D-BUS (a work that I think people would like to avoid, or not, as Li > commented), or create a bridge layer: compiz (dbus) <=> bridge <=> > at-spi (corba), so ATs can communicate with the accessibility > resources that reside inside compiz. >
No reason we can't have a Compiz plugin that speaks AT-SPI. Or a Compiz plugin that exposes a DBUS/whatever interface, that in turn is driven by a magnifier AT that speaks AT-SPI. Lots of options. >> Also, to the extent that Compiz isn't everywhere because of lack of >> video hardware... I think it is worth comparing what we can do without >> GL to what we can do with it; the kind of functionality in products like >> ZoomText (that we can most easily do with GL) that users like and use; >> and the cost impact of requiring what is now essentially a $50 add-on >> video card with GL support (and which can be found in nearly every new >> system being sold today) vs. the $600 software ZoomText. >> > > Everything that is done in ZoomText can be done in gnome-mag and > without using GL, due the power of the XRender extension. A thing that > I have in mind, but I will not address if we decide to move > magnification inside a compositor, is change how gnome-mag draw the > magnifier image from: > > Recevie XDamage and Window related events => Composite the desktop > image in an off-screen drawable => Fetch the desired portion to be > magnified to gnome-mag memory space => Apply filters and magnify => > Send to the magnifier window the magnified image. > > to: > > Recevie XDamage and Window related events => Composite the desktop > image in an off-screen drawable => Use XRender to magnifiy in the > magnifier window. > > XRender can also be used to apply some filters while magnifying, like > invert colors (maybe brightness and contrast manipulation is also > possible), but if a colorblind filter must be applied we must fetch > the parts of the screen, turning the magnification similar to the one > that we have today. > > This will have a great impact in performance IMHO, since various > drivers accelerate the XRender extension. > Interesting. How might you add to this an alpha-blended layer that other process can draw into that would be layered on top of everything else? How about the ZoomText sharpening filter that makes sharp edges for magnified text? Font substitution? >> I personally believe that making a fantastic magnification (and reading >> assistance) system that requires 5-year old video hardware with a >> minimum of GL support & that the user install a new (and tested) window >> manager is a better alternative to much more limited functionality or >> something that is much harder to develop/maintain/etc. but which works >> at least somewhat with older video hardware and with the window manager >> that comes as a default on the desktop today. >> > > I don't understand what you say in this paragraph, can you formulate > it different please? > Assume that without GL, we can have a magnifier of quality 5, and with GL a magnifier of quality 10 (just an assumption for sake of argument, please bear with me). Since GL now runs on even somewhat older video hardware, and you can get a GL card for not much money if you don't have one already, I believe it would be better to make the decision to require GL in the magnifier. Have some simple, basic magnifier that works everywhere so folks who cannot get GL hardware have something reasonable (perhaps quality level 3 - the point here is to focus resources on the great stuff that we believe most folks will be able to get with minimal hardware investment). And then focus on the GL based stuff. Now, this assumes a big difference in what we can do with and without GL. That may be a bad assumption on my part. But I look at how GL hardware can do things like magnification of videos with little to no slowdown in video performance, and I imagine the other cool things GL can give us. And note what I said before: >> But you are closer to the code than I am. These are suggestions to the gnome-mag dude, to consider as he charts the future. Regards, Peter Korn Accessibility Architect, Sun Microsystems, Inc. _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
