[PATCH] Add trim support to qapitrace GUI app

[Dan McCabe]

On 03/16/2012 12:10 PM, Carl Worth wrote:
> On Thu, 15 Mar 2012 22:13:54 -0400, Zack Rusin<zack at kde.org>  wrote:
>> To be honest the ideal way that feature would be implemented would be if it
>> actually trimmed the trace right in the view,
> That would be ideal. Particularly if there were an easy way to show a
> final-frame result.
>
> With good support for something like that, you could select multiple
> calls and have a mode where the preview only showed the results of the
> selected calls. (Then, you'd have "Save" and "Save selected" as an
> independent operation.)
>
>> My biggest worry for the gui was always that it might deteriorate into a bad
>> wrapper for the console tools. By a bad wrapper I mean that it's going to be
>> harder to do things in the gui than it is to them from the command line and
>> unfortunately that's the case for this feature. It's simply faster and easier
>> to copy the current call idx from the detail view and paste it into a
>> echo<paste here>|xargs -i apitrace trim --callset 0-{} -o trimmed.trace.{}
>> app.trace&&  qapitrace trimmed.trace.{}
> You're definitely a wizard to call that command-line "easy". I think
> that sets a pretty low bar for what we could make the gui do that would
> be better.
>
>> So doing things in the gui just for the sake of doing them in the gui when the
>> console tools are a lot more effective seems counter productive. Gui should
>> always improve upon the console tools.
> That seems a reasonable goal to me. And the visual feedback of the
> per-frame thumbnails is already an advantage of the gui for this
> feature, (as Dan mentioned).
>
> So it sounds like what we would need to improve on this feature would
> be:
>
>    1. Default to saving trimmed trace in the same directory as
>       original trace.
This is already implemented in the original patch.
>    2. Default name for trimmed trace should be modified version of
>       original trace.
That is already implemented in the original patch. If the program's name 
is "foo" and the trace is "foo.trace", the patch creates 
"foo.trim.trace", "foo.1.trim.trace", "foo.2.trim.trace", etc., in 
sequence as names collide with previous trimmed traces. As previously 
indicated, this is exactly the same mechanism that is used to create 
traces when there are name collisions.
>    3. Trimmed trace should be reloaded in the GUI after trim.
Will do.
>
>    4. Time-and-reload could be performed without any new file output.
This is more work and I will assess the impact prior to committing to do 
it. This also relates to my next comment.
> Those all seem like useful things that could be implemented
> independently. And of course, a final optimization might involve not
> calling out to the "apitrace trim" command-line tool at all.
This requires refactoring the CLI tool. What is needed is a trace 
management library (including trimming) that can be shared by both the 
CLI too and the GUI tool. I suspect that there is already a bit of 
duplication of functionality, but I haven't reviewed the CLI code in 
sufficient detail to be certain of that. I've only focuses on the GUI tool.
>
> I won't express any opinion on how much functionality should be
> implemented before the changes are accepted upstream. That's not my
> call.
>
> -Carl
>