Re: D-BUS based magnification API

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

Hi Peter,

After reading lot's of messages (from 2005 to today) about the
Metacity development, I don't think that the GNOME community want to
switch Metacity due all the maintenance that it have and the good
integration that it have with GNOME and I really don't want to start
this discussion again!

Anyway, there is still some development in it, as can be seen in the
bugzilla component related to it.

So, I get back in my comments about Compiz and reconsider Metacity as
good house for magnification.

After reading some old messages
(http://mail.gnome.org/archives/metacity-devel-list/2006-October/msg00006.html)
the idea to use "unmanaged" zoom regions was already there.

When a compositor is running, gnome-mag can create the windows needed
and pass they to the metacity (the mechanism to do it can be generic,
so we can support others WCM) compositor so it will draw the
composited scene in it. This way we can separate the Compositor from
the Magnifier, what is good from my point of view, since we can re-use
much of the code in a port of the magnifier utiliy.

I will look with more attention to the XRender operators and GL pixel
operations to see how we can implement image filters in an efficient
manner.

2007/8/30, Peter Korn <Peter Korn sun com>:
> >> 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 don't think that other process must draw in the magnifier zoom
region, since it will be very difficult to control these draws, since
other process doesn't want/need to know about stack orders, their
vision is that they are the only one application running (in majority
of the cases) and as must we can leave this that way, it's better.

What I think is that for some applications we can extend the WMH
(Window Manager Hints), so an window can set some hints that instruct
the magnifier or the compositor to apply some effect, as an example
you can think of what MacOS X have in their panel control when you are
searching for a certain configuration. The itens that match best are
highlighted. We can also implement some good effects to text reading,
as cited by Willie, ATs can communicate what they are doing, like
reading a word, a letter a phrase and the magnifier/compositor can put
a square around it, highlight it, or any other thing. This idea can
also be usefull to the cases that you cited about cognitive
impairments.

For fonts we can wrap cairo, so an SVG representation is also created
of the font and/or image created, and then the magnifier/compositor
uses this SVG render a good quality font to the user. I post some
experimentation that I made in my blog: http://blogs.gnome.org/carlosd

These things are a lot of work and are the ones that will keep me
occupied during the next release cycle. Only FYI, I will work more on
this:

* Make the "unmanaged" zoom region concept work;

* Verify the possibility to use XRender or GL to implement the actual
magnifier filters;

* Develop a cairo wrap, so SVG representations can be available for
the magnifier/compositor.

Only to make a complement to this e-mail. All the things cited in:
http://live.gnome.org/GAP/Magnification are already implemented in
gnome-mag and there is also some features that is in gnome-mag that
isn't cited in the wiki. gnome-mag also run quite well in old
hardware, a modern GNOME don't! Thanks to all hard work done by the
Sun guys to achieve this!

Maybe the ideas that I put in this e-mail change again, but I'm loving
this brainstorm!

Best regards,
Carlos.