Handling of OUT function arguments for "apitrace trim"

[Carl Worth]

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.

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.

Meanwhile, I'll start writing code to do more thorough trimming. I think
that my next effort will be to identify "live" vs. "dead" textures
within the desired range and then to discard operations that update dead
textures.

I'm not currently worrying about dead state updates, (trying to keep the
amount of state-tracking code to a minimum while hitting the most
important kinds of trimming).

As I said, I would be glad to hear feedback from anyone on the code I
have here so far.

Thanks,

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20111117/4aaf1868/attachment.pgp>