Re: [g-a-devel] Questions about the gnome-mag design

[Bill Haneman <Bill Haneman Sun COM>]

Carlos;

We consider magnification to be a service.  As such, it needs an IPC 
model for communication.

In my experience, the separation between the magnification service and 
the magnification client makes debugging _easier_ and greatly reduces 
the performance problems encountered if the magnification service is in 
the same process space as the client.

Carlos Eduardo Rodrigues Diogenes wrote:

> Hi Bill,
>
> I have some considerations about the gnome-mag design that I would 
> like to argue.
>
> Don't you think that the IDL interface only increases the complexity 
> to debug and difficult contributions from new developers to the project? 

I don't believe that the IDL presents much of a barrier, compared to the 
difficulty of dealing with a performant, asynchronous magnification 
client that handles both region updates, scrolling, and 'DAMAGE' 
notifications.  The IDL interface is only a small, nearly trivial part 
of gnome-mag.

I do think that some IPC mechanism other than CORBA may make sense, for 
instance I would support a dbus-based IPC protocol, but the separation 
between client (gnopernicus) and magnifier service (gnome-mag) is a 
critical part of the design.

> What are the reasons to have this type of design? I'm asking it 
> because I think that the process to listen the system events, process 
> they and show the magnified area can be done in a single program and 
> this way is much more simple to develop the system.

Simple, maybe, but the end result would be harder to debug (the 
magnifier logic would become intertwined with the client's), and more 
subject to performance problems since the magnifier would be easily 
"starved" for resources by the calling program.

> What do you think in an effort to merge what BAUM developed in 
> gnopernicus with gnome-mag to create a complete solution for 
> magnification, eliminating these CORBA dependecies/complexities?

This was explicitly avoided when gnopernicus, gnome-mag, and at-spi were 
initially designed, for many reasons.

> Why not design gnome-mag to be a library (or only a program like I 
> said in the last paragraph) that support magnification and export an 
> API in C? I have doubts if making this program an object that can be 
> accessed throw CORBA is the best solution.

Creating a new set of client bindings with a C api may be reasonable, 
but there is already a C API - the one defined by the CORBA and IDL 
specification.  In any case this would need to wrap a client-server 
model, so some other IPC mechanism would have to be substituted for the 
CORBA one. 

There are a number of areas where magnification can be improved, but I 
don't think that this one would give much useful improvement compared to 
the effort involved, and could be harmful. 

Better improvements would include:

* a multi-pass rendering system, so that better smoothing algorithms 
could be added to gnome-mag without slowing the panning performance 
unacceptably;
* use of COMPOSITE to provide fullscreen magnification without requiring 
a virtual screen, and to reduce the "flicker" and "jaggies";
* better documentation of the Magnifier and ZoomRegion properties interface.

best regards

Bill

> Thanks,
> Carlos.
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel