Taylor: Avoiding Jitter in Composited Frame Display

The desktop have 2 buffers, one is visible while the other is been draw.

Imagine the compositor as drawing a 3D scene where there is single rectangle for each window and its content is rendered from texture. The composer (at the moment) seems to be executed right after buffers are swapped.

The problem seems to arise when the program is sending commands to draw into the texture. Either the texture would be in incomplete state when it is time to compose the desktop (e.g. async drawing) OR the server should wait for the texture update to finish before calling compose and showing the desktop.

There are 4 ways to solve this:
1. Use 2 textures. Draw into new texture. The composer would use the old one until the new one is complete.
Problems: Doubles memory usage. The server doesn't know if it should copy the content of the old texture, so the app could only modify it. As backing store have been removed, I'd say it expects the program to draw the window(texture) in full (but that's slow...). With current composer it also adds latency to output(draw,texture,compose,swap).

2. Use 2 textures, one scratch pad and one for composing. When drawing is done, XSync and XFlush commands would copy the scratchpad into the composing texture. This is indeed variation of #1. The difference is that you have a backing store (preserving the content of previous drawing) for free. As modern toolkits draw everything in ram and just blit it, it makes sense for scratch pad to be in RAM. Of course blit takes time so you may need #4 to control it. Why use this method then? The application may issue a long and complicated drawing instructions. If we have to care only for a single blit, we will know how much time it would take.
Problems: Additional copy makes things slower.

(tylors' methods)
3. Hold the redraw/damage events until after desktop framebuffer is swapped (and new image is composed). When received, these events cause the application to issue new drawing commands. The hold would ensure that redrawing starts when there is still a lot of time. This technique is actually quite useful for non-composite case, where you can have damage from moving one window over the other (overlapping). There are no per window textures only desktop frame buffer(s).

4. Withhold the drawing commands if the time for swap is near. Since X is client-server protocol, the program doesn't have full control when the commands are executed.

There are other tricks that could be used, but they require synchronizing with the video card. Stuff like knowing what is the current line that is been output, when the vblank begins, when it ends. Things that were possible with CGA,EGA and VGA.

And don't get me started on video playback issues...