On Fri, 15 Apr 2005 11:50:09 +0100 Simon Poole <[EMAIL PROTECTED]> babbled: > 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. ok - well i guess then /dev/fbX has that exported then - so no worries :) > 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) actually - you can simplify case 2. render updates to back-buf. flip buffers (back and front buf swap) copy rendered pixels from update rects from front buf TO back buf (so at worst the extra overhead is a full memcopy of the screen per frame. its less than a re-composite, but not insignificant). now backbuf is the same as frontbuf and update renders will display correctly :) the OTHER solution is to have all objects have triple-state. currently they have current and previous states - that's how evas figures out update deltas based on previous object state (geometry, properties, visibility etc.). you'd need to ass a 3rd state to track then you always calculate deltas between cur and prev2 not cur and prev. each render u copy start from prev to prev2 and cur to prev. > 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. true. as i said - the optimal solution is by far the most complex and most wide-reaching and its beyond the engine. > 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. well the copy method sounds sane - you can add it as an engine init parameter that the fb engine only has. so it can be enabled/disabled at init time - or any time during runtime (so turn it on when you care, turn it off when u don't care anymore). :) so make it part of the engine info - and then all we need is ecore_evas exporting some control over it :) > -- > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) ------------------------------------------------------- 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
