Carsten Haitzler (The Rasterman) wrote:
> the only way to do this is literally use hardware double buffering and flip
> buffers - but this violates the first law of "assume the buffer was as we
> left it" because it isnt - as u swap buffers your "rendering" changes to the
> new backbuf that is swapped out from the screen. ie this is the canvas 2
> renders ago (not 1 render). so to do "vsync swaps" you 1. need to be able to
> copy pixels to the fb faster than the scanline can scan. 2. arrange copies to
> happen top to bottom in "screen space" (if there are multiple update rects
> that are disjoint u may have to order copies scanline by scanline from
> multiple rects that share the same horizontal scan). but if this still is not
> faster than the scanline fb read... you are... in trouble :)
Thanks for the detailed response. I see the problem.
My 200MHz ARM platform has enough memory to permit double buffering, but
as you rightly suggest, maybe not the bus bandwidth to do updates during
vsync.
When I use h/w double buffering, I can tell the framebuffer driver to
flip without any overhead (simply writes to a register), and the video
subsystem automatically waits (asynchronously) until the next vertical
retrace to apply the change.
Could you see the following working?:
1. Render updates to buffer2 (offscreen)
2. Flip buffers - buffer1 goes offscreen, buffer2 now onscreen
3. Render same updates to buffer1 (now offscreen)
This doubles the amount of work in each render, which is particularly
bad if the depth-mapping and dithering is done on the fly. So, triple
buffering could improve performance at the cost of more memory:
1. Render updates to buffer3 (offscreen)
2. memcpy updates from buffer3 to buffer2 (offscreen)
3. Flip buffers - buffer1 goes offscreen, buffer2 now onscreen
4. memcpy updates from buffer3 to buffer1 (now offscreen)
This still has the obvious limitations over the current model: (a)
larger memory requirements, (b) slower and (c) only offers a solution
for the framebuffer. However, all of these are completely under my
control for an embedded system UI, which is what I'd like to use EFL
for. If implemented correctly, it could be a compile-time option which
is disabled by default.
Does any of this sound sane? Like you, I'm not convinced it would be
worth the effort yet, but I'd like to make sure my options are open.
--
Simon Poole
www.appliancestudio.com
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
