Re: [AGG] Animation in win32 with AGG

[Stephan A. <sup...@gm...>]

peter wrote (2007-08-29, 01:54:08 [+0200]):
> But..
> Generally, rendering speed is slower than blittng speed.. this means 
> input speed is slower than output speed. In this case..how can harmonize 
> in/out speed in pre-render buffer ??

I have had good experience with running a rendering thread and a display 
thread. I don't know if you can set thread "priorities" on Windows, I have 
never programmed on that platform, but I set the display thread priority to 
very high (like realtime or something), and the rendering thread priority 
to low or "normal". The rendering and display thread are synchronized via 
locks that protect the output buffers. Ie, the generator blocks on a buffer 
that is being displayed, the display thread blocks on a buffer when it is 
still being rendered (ie the rendering is too slow). The display thread 
would wakeup in exact intervals, try to grab the next buffer (lock it) and 
display it. Then it goes back to sleep. When it wakes up the next time, it 
grabs the next buffer, switches the display and unlocks the previous 
buffer. The rendering thread tries to grab buffers as quickly as possible 
and eventually blocks on the buffer that is currently being displayed. So 
ideally, the rendering is (on average!) faster than the pace of displayed 
buffers. How many buffers you need depends on wether the system needs to be 
responsive to user input (few buffers), like seeking in the video or 
animating objects. The delay with which the user sees the effects of what 
he is doing equals to the number of buffers that are between generating and 
displaying. If you playback a static animation with no interaction from the 
user, you can use a lot of buffers and that will compensate any changes in 
demands to computing the buffers. Ie, the playback will survive short peaks 
where the rendering takes longer than the buffer display duration. The 
purpose of this system is to play back buffers at a fixed rate, so it's 
completely unsuited to playing back as fast as possible. But in my 
experience, and with CRTs fading out, it is good to playback at a fixed 
framerate of 60 fps (your LCD's native refresh rate) or at 30 fps (just as 
smooth). The wakeup of the display thread can be synced to the vertical 
refresh of your display.

Here is some ASCII art to visualize what I have tried to explain. (In case 
you are looking at emails with a proportional font, you are getting what 
you deserve.) If other developers have some input, I would appreciate to 
hear it of course. :-)

Here is the ring buffer, the numbers are the index of the buffers and in 
the brackets, I have indicated the frame of the animation they contain:

      renderer just finished frame "21", blocks on the lock for buffer "4".
      |
      V
.-----3 [21]-->-.
|               |
2 [20]          4 [18]  <------currently being displayed
|               |
.--<---1 [19]---.

When the display thread wakes up at the vertical sync, it will try to lock 
buffer "1", display it and unlock buffer "4". At this point, the generator 
is allowed to render the next frame.

But all of this is highly off-topic... :-)

Best regards,
-Stephan