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

[Carlos Eduardo Rodrigues Diogenes <cerdiogenes yahoo com br>]

Bill Haneman wrote:

> 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 agree with you that the separation of these two process are important 
and I think that I really understand the  importance of CORBA (or other 
IPC mechanism) to achieve this goal.

Just for information, what is scrolling?

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

Could you list the more important/relevants reasons? They are these ones 
that are still on the text, or have any others?

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

Could you explain better what is a multi-pass rendering system or point 
to some resources?

what is panning? I search it in dictionaries, but don't find anything 
meaningful.

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