Handling of OUT function arguments for "apitrace trim"
jose.r.fonseca at gmail.com
Thu Nov 24 09:03:20 PST 2011
On Fri, Nov 18, 2011 at 12:04 AM, Carl Worth <cworth at cworth.org> wrote:
> On Wed, 16 Nov 2011 23:00:01 +0000, José Fonseca <jose.r.fonseca at gmail.com> wrote:
>> if you wanna guarantee "apitrace trim" 's output to be future proof then
>> it might be better to preserve this somehow, by putting a flag in the
>> arguments, or in the call signature.
> OK, so that wasn't too hard to do.
> I'm very glad I did it because it let me do byte-by-byte comparisons of
> uncompressed traces (before and after a ''trim'' copy). And in doing
> that I found that doubles in the original trace we turning into floats
> in the new trace. That was another case of the current parser throwing
> away information (with a single Float class) and also easy to fix.
Ah, yes, good catch.
> So I've got a preliminary "apitrace trim" command ready for you to look
> at in the apitrace-trim branch of my repository.
> It doesn't trim much yet. It accepts a range of calls and will discard
> any drawing operations outside that range. All non-drawing operations
> are preserved (regardless of whether they are inside or outside the
> So that's marginally useful in its current state. Mostly, I'm sharing it
> for some early feedback.
> Obviously, the construct in the final commit (_classify_call, and
> _call_is_draw) will need to be reimplemented to some extent. This
> doesn't belong in cli_trim.cpp but will be generally useful (for
> "apitrace dump-images", etc.). So, José, I'd like to hear your
> suggestion on how that should be implemented. Do you want some
> c-plus-plus-y derived parser class and derived Class object so that
> GL-specific users of the parser can annotate and query parsed objects in
> this way. Let me know what you'd like to see.
My idea here is to modify :
- for old traces the parser will reconstruct the flags based on the
- for new traces the function signatures themselves will have the flags
The flags I though of having in the trace file are:
- frame complete (SwapBuffers, FrameTerminatorGREMEDY)
- swapdrawbuffer (SwapBuffers, BindFramebuffer)
- draw (DrawFoo, Clear)
I want the flags to be relatively api agnostic.
So any more detail than above, should be done in a parser. It looks
like what you want is a TrackingParser which has API specific
knowledge and keeps track of the state as it parsers the calls.
More information about the apitrace