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

["Carlos Eduardo Rodrigues Diógenes" <cerdiogenes yahoo com br>]

Hi Peter,

2007/8/29, Peter Korn <Peter Korn sun com>:
> Hi Carlos,
>
> In two places you mention going with Metacity:
>
> > ...
> >
> >> * Understanding where the masses are going with respect the
> >>   composite extension manager.  Is it metacity, compiz, something
> >>   else?  Where/how does gnome-mag fit in this new world?
> >>
> >
> > There was a big discussion about the Metacity compositor and compiz:
> > http://mail.gnome.org/archives/desktop-devel-list/2006-October/msg00011.html
> > and GNOME appear that will not replace Metacity by Compiz. The
> > discussion is quite old and things maybe changed, but I didn't saw any
> > other discussion about a replacement, so the path, IMHO, is metacity.
> >
> > If Metacity doesn't introduce composite effects some day (something
> > that I doubt) we already have basic composite (let's say that the code
> > to track windows is there :-) being done in gnome-mag.
> >
> > We must have a compositor and appear that the best path, considering
> > the effects cited in the other messages, is to use Metacity, since
> > it's still have a good architecture (thanks Sandmann) IMHO. Moreover,
> > in reply to Eitan (I send if the wrong e-mail, so it doesn't appear
> > yet in the list), I cited about an way to keep the resolution of text
> > and SVG images in the magnified image, that is: wrap cairo and, when
> > the magnifier is activated, instead of draw (or instead of only draw) in the
> > application window, an SVG representation is created and the magnifier
> > is notified about it and about updates in this SVG. I thought in this
> > in something in the same layer as AT-SPI. Then when the magnifier
> > compose the final screen it will draw the window pixmap and render the
> > SVG.
> >
> > In this world, gnome-mag doesn't fit.
> >
> >
> > ...
> > If there is no one oppositing to implement gnome-mag API inside
> > metacity I will start this work without further discussions (I think
> > that I was the only one against it in the past :-) starting with the
> > actual gnome-mag API, since this is the basic that we need, than we
> > can start to think how these interaction can be done, since they must
> > be carried on by the WCM.
> >
> > The needs for the applications cited by Peter Korn can also be addressed here.
> >
>
> 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.

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

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

>
>
> But you are closer to the code than I am.  Perhaps the downsides to
> going the Metacity route are more minimal than I suggest they are...
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>