Re: [g-a-devel] comosite based magnifier design

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

Hi Bill,

I was reading some messages in the Xorg list about what is need to 
finish the composite extension. Somethings are very interesting.

When I talked about all that logic, it was because composite (now) 
doesn't have a way to you say something like this: "please redirect the 
root window to off-screen and include all it's child, except my 
magnification screen", but what I saw there is that we will be able to 
do it, so the problem to capture the screen becomes simple.

I'm excited, because this is what I wanted when I first start to think 
about an magnification program, but don't have the expertise to do.

Thanks,
Carlos.

Bill Haneman wrote:

> Hi Carlos:
>
> Regarding gnome-mag and COMPOSITE, I am not sure that use of COMPOSITE 
> requires that the entire rescaled display be stored.  gnome-mag 
> currently does this for simplicity, but of course it would be better 
> to store only the current viewport plus a certain margin.  Some sort 
> of "prefetch" would be better still, for fast panning.
>
> As far as COMPOSITE goes, it's always possible to generate 'expose' 
> events for parts of the screen which the magnifier has discarded, so I 
> don't think COMPOSITE would force you to store the entire screen.
>
> I would not personally advise using shared memory, and don't see the 
> need.  Sharing GDK structures, in particular, across multiple threads 
> can be tricky, and unless you have multiple CPU cores I don't see much 
> advantage.  All of the tasks you discuss below in "proc1" already have 
> to be done by the compositing manager, this is not such a complex task 
> in my opinion.  I think that the rescaling code needs to be closely 
> coupled to DAMAGE events, since otherwise you will have to resort to 
> polling or else just passing events from your compositor to the 
> rescaling engine.
>
> I would advise using a single threaded compositor which rescales as 
> part of the compositing operation.  Optionally it could discard all 
> pixels that fell outside of a configurable margin around the current 
> viewport, and generate 'expose' events when new areas were scrolled 
> into view (which would result in their being re-composited).
>
> In the above case, it will be a tradeoff between speed and memory 
> size, since throwing away regions will cause re-compositing to take 
> place.  However, for very high magnifications, you might end up 
> improving speed as well, since the excluded regions won't have to be 
> composited/rescaled, as long as the user doesn't frequently pan over 
> the entire screen.  There may be an optimum size for the margin around 
> the viewport, and at small magnification factors it may be best to 
> magnify the whole screen.
>
> regards
>
> Bill
>
> Carlos Eduardo R. Diógenes wrote:
>
> > Hi,
> >
> > I was thinking about a composite based magnifier and
> > have some ideas how it can be implemented, but I'd
> > like to argue about it before starting coding the
> > solution this way.
> >
> > First, I don't think that is a good solution have all
> > the screen magnified, because the amount of space
> > needed to store magnifications above 4x. If I'm not
> > wrong, this was percepted in gnome-mag too.
> >
> > I think that a good way to implement it (a composite
> > based magnifier) is divide the actual gnome-mag
> > implementation in two process that colaborate through
> > shared memory.
> >
> > One process (proc1) will track the changes in the
> > screen and composite the actual screen in the shared
> > memory (with no magnification). I think that this is a
> > complex task, because this need to be made as fastest
> > as possible and the cost to composite is high (the
> > problem is bigger when you have many windows), and
> > putting all this logic (verify created, moved,
> > resized, exposed windows) to keep the screen in the
> > shared memory updated in a separated process will
> > simplify the things and make updates easy.
> >
> > The second process will do something very similar of
> > what gnome-mag is doing, the only difference is that
> > this other process (proc2) will not have anymore to
> > take the screen from the video memory, but from the
> > shared memory (maybe there is a need to be a flag to
> > indicate that proc1 is updating the image) and will
> > not have anymore to track damage events too.
> >
> > Questions, sugestions or criticals are very welcome,
> >
> > Thanks,
> > Carlos.
> >
> >
> >     
> >
> >
> >
> >     
> >        
> > _______________________________________________________ Yahoo! doce 
> > lar. Faça do Yahoo! sua homepage. http://br.yahoo.com/homepageset.html
> > _______________________________________________
> > Gnome-accessibility-devel mailing list
> > Gnome-accessibility-devel gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
> >