Re: [g-a-devel] gnome-mag, full screen magnication and composite

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

Hi Bill,

On Mon, 2006-06-26 at 16:36 +0100, Bill Haneman wrote:
> > Hi guys,
> > 
> > I was thinking about gnome-mag and full screen magnification. The only
> > way that we can achieve this feature today is throw composite, but I
> > really doubt if we must use this technology, so I want to here what our
> > community members have in mind about this.
> 
> Hi Carlos:
> 
> I don't see why we have to emulate all those window-manager-like features 
> just to use Composite.  When I looked at this (well over a year ago),
> it seemed to me that we only needed to add magnification logic 
> to a simple compositing manager like the existing one that
> was available with the XOrg composite client code.  At the time it 
> didn't' look like a lot of code.

We must emulate some of the window-manager-like features to know about
what is happening with the windows, so we can a fine control what must
be composed, because without a good use of what we must compose we will
push down perfomance. I don't think that it's a premature optimization,
because I don't think in it like the right solution. We don't need do
duplicate efforts. The xserver can do this work for us so more easy.

Moreover, putting this in the xserver we will being creating the
mechanisms to improve the gnome-mag, or anyother magnifier, API a lot
and with a lot of flexibility and less code.

How Composite does the things is more suitable to applications that want
to add a eye-kind desktop to the user and low-vision users don't like
this, for they the desktop must be the as simple as possible, without
effects. They prefer static things.

> 
> I believe that basically we'd just need to use Composite's capability
> to prune the window tree, separate our magnifier window out, and 
> render only that window to the screen after compositing directly
> into it.  

It will so much easy if we can ask a piece of the window, manipulate it
like we want (using xrender or any other mechanism/algorithm) and then
draw in the magnifier window (the only window that goes to screen
memory). The changes to gnome-mag will be minors.

> 
> Why is it not that straightforward?  I don't understand the problem 
> you seem concerned about...

Because we must implement a composite manager or embbed magnifier logic
in window-managers. The first will only have good performance in good
computers with good video cards. This is not a big problem, since the
prices are lowering more and more, but we still with a glue code in the
application that can be avoided. The later sounds very terrible to me,
since magnifiers and window-managers are to distinct things. I, like a
magnifier developer don't want to worry in my code with some question
related about window-manager, and I think that the vice-versa is true.
Moreover, a window-manager is a policy while, for me and I think to you
too, the magnifier service is a mechanism.

> 
> regards,
> 
> Bill
> 
> > If we use composite in gnome-mag we must have a window-manager like code
> > in it to manage windows that come and goes, windows overlap, so we must
> > track a lot of events and use clip lists, I don't know if the server can
> > generate clip list to us, to render only the window parts the will be
> > showed in the screen. I think that we can make a good job on this to
> > maintaim the magnifier responsive in the case that the user don't have a
> > good video card, but we still with a memory problem, because with
> > composite each window is maintained in off-screen memory. This is not a
> > big problem to new video cards, but I think that we could, and must do
> > this work in older hardware.
> > 
> > Another solution that is hitting my head is that we could change a bit
> > the server, so we put the magnifier window in top of all others,
> > something like the OverlayWindow in composite, and paint the contents of
> > all windows below it in a pixmap with the same properties of the root
> > window using the same algorithm that is already used in the server.
> > 
> > I think that this second solution is better, but maybe there are reasons
> > to doesn't try it there I don't realize here. I'm very motivated to try
> > this, so if there isn't any good arguments to forget this possibility I
> > will start to play.
> > 
> > Thanks,
> 
-- 
Carlos Eduardo Rodrigues Diógenes
Projeto xLupa - http://www.unioeste.br/projetos/xlupa