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



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

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.  

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

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,




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]