GNOME.org
 

Re: [g-a-devel] D-BUS based magnification API

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.
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]