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

[Bill Haneman <Bill Haneman Sun COM>]

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
>