Re: [E-devel] evas tearing / vsync

[Carsten H. (T. R. <ra...@ra...>]

On Thu, 14 Apr 2005 15:03:40 +0100 Simon Poole <sim...@th...> babbled:

> I'm just starting to play with Evas and Ecore and have done myself a 
> little hello world bouncing box (using an ecore timer to move an evas 
> rectangle object around the screen).
> 
> I am seeing some tearing in the animation, and wondered if anyone knew 
> anything about vsync support in Evas?  Is the fb engine supposed to be 

evas doesnt attempt to vsync - well ok - non of the existing engines do. this is an engine internal matter. software x11 rendering really provides no vsync because x itself guarantees none. evas basically calculated damage regions and re-renders. it maintains NO off-screen buffers for double-buffering and thus vsync rendering n kid of hard as u need to do an entire buffer flip at that time. since no other-buffer exists - this is kind of hard to do. the reason behind this is several fold. 1. to keep memory requirements during rendering to a minimum and 2. to keep handling updates simple. evas composites/renders one UPDATE at a time and assumes the front buffer is exactly as it left it last time it rendered. this depends on your engine though.

> synchronized with vsync to avoid tearing?  Is there some incantation I 
> can utter to activate it?  If not, I'd like to implement it.  Anyone 
> able to help?

for the fb engine this would require the framebuffer device to support userspace being able to get a vsync interrupt - i don't know how to do this with /dev/fb - if it is possible at all. also remember vsync stuff will SLOW things down as u need to WAIT for the vsync - this is valuable time you could have spent rendering :) that's why i haven't done it. to do it effectively you will need to keep the outbuf's stored for each update and then on a flush - write each outbuf and free it.

evas's core renderer pretty much works by doing this (for every engine)

1. caluclate minimal render deltas (assuming canvas pixels are the same as the last time it rendered - except for damage regions)
2. pass these to the engine
3. engine gives them back as a list of update rects as the engine things they shoudl be handled.
4. loop through each rect
  1. ask for scratch compositing buffer
  2. composite from bottom to top within this update everything that intersects and should be drawn (cutting out rendering for fully opaque regions that will be copied on top later on in the compositing - eg big opaque images or rects on the top will ensure evas never renders underneath them before drawing over them)
  3. convert thus back-buffer to the screen (this may be anything from a memcpy to a convert from 32bpp to 16bpp with dithering and rotation and then punted to X via xshmputimage/xputimage - depends on the engine again).
  4. destroy scratch buffer
  5. repeat this loop until no more update regions are left
5. call engine flush

so to make a go of vsync u'd need to make stage 3 of the loop defer the copy to the fb by marking that buffer as "must copy this to x,y in the fb with rotation z etc. etc." and when u destroy such a marked buffer you dont destroy - you put on the flush list instead. when flush is called you wait till vblank interrupt (or until the "electron gun" has scanned pas the bottom most update rect - you dont have to wait till it hits the vblank - as long as its after the bottom most update buffer rect on the output), then very quickly copy the buffers in the flush list to the screen asap and destroy them. IF the screen format is not the same as the buffer format (16bpp for example) you want to convert the buffer in an earlier stage to screen depth but not copy it to screen. this is an issue with the fb engine as it converts the argb 32bit buffer DIRECTLY to the screen avoiding intermediate copies (thus gaining more speed) BUT even if u wait for vblank - it is possible your copy to screen is slower than the vscan speed and the scanline will catch up to your copy as you copy it... and you'll be back to having tearing :)

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 :)

anyway... that should give you a clue or 2 :) personally i haven't done this as i haven't seen it a high priority compared to the effort to make it work - and as u cant really do it for things like x software rendering (the double buffer extension doesn't guarantee vsync swaps either) and i havent looked at how/IF it can be done with /dev/fb - and since it invariably would mean sleep/poll/wait loops eating up valuable cpu resources waiting on a vblank... thus reducing performance... :)

> Clues appreciated.
> 
> --
> 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
> enl...@li...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ra...@ra...
裸好多                              ra...@de...
Tokyo, Japan (東京 日本)