[Chromium-dev] runaway rendering

[Keith W. <ke...@tu...>]

I've been running through the mesa demos using chromium against software mesa
and a symlink libGL.so-->libcrfaker.so.

One thing I've noticed is the potential for large latencies arising from the
way chromium decouples the application from the rendering back end, with
buffering in between.  The typical case is an application that emits small
(data-wise) but slow-to-render frames in a loop.  The Mesa gloss demo works
for software rendering, the q3 menu screens are good examples of this that can
trap hardware renderers fairly easily.

This is a common problem that's been addressed in basically every hardware gl
driver - especially since q3 and earlier quakes demonstrate the behaviour. 
Typically some sort of flush or synchronization is done on swapbuffers - I
haven't looked closely enough at what's possible in chromium to implement such
a synchronization.

All that would be necessary is for libcrfaker.so to ensure that commands for
frame (n-1) have been *received* by the server at the time the swapbuffers for
frame (n) is issued.  There's no need for hard synchronization or a round trip
in the normal case - just a mechanism where the server notifies the client of
its progress, and allows the number of buffered frames to be tracked.  

This is all based on testing with the simple 'crdemo.conf' setup -- the issues
are going to be more complex for tiled and other scenarios.

Keith