Replace glFinish with OpenGL fences.

Replace glFinish with OpenGL fences.

The glFinish after rendering to a texture serves two purposes:

First, and maybe most importantly, it makes sure that if we send
the texture ID to another thread and try to draw it there, it is
actually valid in that context. (If not, the command to allocate
it could still be stuck in the queue, or the command to draw
the quad to the screen could be queued before the command to
actually render the image to the texture.)

Second, it makes sure we don't overwhelm the GPU with rendering
commands, especially in the readahead thread. GPUs have a long
pipeline, and our commands buffers are typically very short
(we render only one or a few quads per frame), which means that
we could queue so much rendering that we couldn't actually get
to display the frames, or do compositing and other normal UI tasks.
(GPUs are not all that good at scheduling.)

However, glFinish() also has an unwanted side effect: Since the
CPU waits for the GPU to finish, it means it cannot do anything
useful in that period; in particular, it cannot start decoding
input video for the next frame, which is very frequently a win.

Thus, we replace glFinish() with fences: One that we store on the
frame and that the client can wait for, and one that we wait for
ourselves before we render the next frame. The first fulfills
purpose #1 above (although a client that doesn't render in a
different thread can just ignore it), while the second fulfills
purpose #2. #2 does reduce the possible pipelining somewhat
(compared to not having any fence at all), but it seems that
the actual performance lost is very small in practice. In any
case, this is markedly faster than glFinish -- on my Intel HD 3000,
it increases GPU utilization from ~40% to over 80% in a typical
transition.

Note that this is an API change; a client that wants to send
the OpenGL texture number on to a different thread for display,
will now need to wait for the fence before it can actually draw
using it.