Re: Uneven V-sync

Rainer Deyke <[email protected]> Sat, 21 Jan 2017 11:24:27 +0100
Newsgroups gmane.comp.lib.sdl
Message-ID <[email protected]>
On 21.01.2017 01:27, Edition Chamäleon wrote:
> Hi there, is there anyone out there who has a clue why in my case
> (see above) SDL on Android gives such uneven iteration time, even if
> vsync is on and there is almost nothing drawn or calculated?


Why wouldn't it?

Here is how correct triple buffering with vsync works:
   - There are three buffers: the buffer currently being sent to the 
screen (the "screen buffer"), the buffer to which the game is currently 
rendering (the "back buffer"), and the third buffer (the "spare 
buffer").  There is also an "enqueued" bit which indicates if the spare 
buffer is enqueued for being sent to the screen.
   - On RenderPresent, the system does this:
     - Optionally wait for the enqueued bit to be cleared.
     - The back buffer and the spare buffer exchange places.
     - The enqueued bit is set.
   - Meanwhile, the video hardware is in an endless loop:
     - Send screen buffer to physical screen.
     - If the enqueued bit is set:
       - Clear it.
       - The screen buffer and spare buffer exchange places.
     - Repeat.

If the game renders slower than the display refresh rate, then the time 
per frame will always be uneven.  If the game renders faster than the 
display refresh rate, then the time per frame may or may not be uneven 
depending on whether the display driver chooses to wait for the enqueued 
bit to be cleared.  (Waiting saves battery time and ensures that every 
rendered frame is sent to the screen but increases display latency, so 
there are good reason both for and against waiting.  For a mobile 
device, I would expect the reasons for waiting to outweigh the reasons 
against waiting.)


-- 
Rainer Deyke - [email protected]