[PATCH] retrace: Implement glxCopySubBufferMESA

[Alexander Monakov]

On Mon, 28 Oct 2013, Carl Worth wrote:
> >> I'll note that this function, like glFinish and glFlush, is almost, but not
> >> quite, a candidate for "this call concludes drawing a frame" flag.
> 
> You're definitely right. It's strange to replay this chrome trace with
> apparently hundreds of frames in it only to then see:
> 
> 	Rendered 6 frames in 10.9526 secs, average of 0.547816 fps
> 
> I'm not sure what you mean with "almost, but not quite".

ISTR this was discussed previously, but I can't find a reference.  The issue
I'm referring to, glFlush and glFinish (and now glXCopySubBufferMESA) do not
have "hand off a completed frame to the windowing system and start rendering
another one" semantics.  It's closer to "flush the GL command stream, and in
case we're rendering to the front buffer, pray that it will be updated soon,
and without terrible tearing".

It's the same for legacy GL applications that use single-buffered visuals in
combination with glFinish or glFlush: should apitrace detect frame boundaries
on that basis?  I think so.  As it doesn't, I have to wonder if there was a
good reason.

Instead of marking glXCopySubBufferMESA with CALL_FLAG_SWAPBUFFERS (which is
incorrect, in doesn't swap the render target; see the definition at line 42),
I'd suggest to invent a new flag, say, CALL_FLAG_FLUSH_CS, annotate glFlush,
glFinish, glXCopySubBufferMESA with it, and ask the new flag to be or'ed into
CALL_FLAG_SWAPBUFFERS.

Or maybe don't invent a new flag, but simply use existing CALL_FLAG_END_FRAME.
Not sure what would be less wrong.

Perhaps one of the reasons to not treat glFlush/glFinish as frame terminators
was their use in modern double-buffered apps?  Arguably they should not break
the frame when the app is rendering to the back buffer.

I guess marking glXCopySubBufferMESA with CALL_FLAG_END_FRAME and leaving
glFinish/glFlush as they are would be fine.

Thanks.

Alexander