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

[Bill Haneman <Bill Haneman Sun COM>]

On Sun, 2006-06-25 at 18:33, Carlos Eduardo Rodrigues Di�es wrote:
> 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 I agree with your assessment.  Perhaps you could be more
explicit?  Why would we need to do more clipping/checking that the
existing compositing manager?  At most, we would want to keep track of
the current magnified viewport.

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

I don't recommend this - we had extensive discussions with the XServer
development community about magnification needs, and Composite is what
we got.  Writing a new Xserver extension, and getting it accepted, which
is what you are proposing, doesn't seem like a reasonable thing to do
until we first try to make full use of the new XServer extension that
was already written in part to try and solve our magnification issues.

regards,

Bill

> 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�es
> Projeto xLupa - http://www.unioeste.br/projetos/xlupa
> 
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel