Handling of OUT function arguments for "apitrace trim"

[José Fonseca]

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
> range).
>
> 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.


Jose