[PATCH] Add trim support to qapitrace GUI app

[Carl Worth]

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.

  2. Default name for trimmed trace should be modified version of
     original trace.

  3. Trimmed trace should be reloaded in the GUI after trim.

  4. Time-and-reload could be performed without any new file output.

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.

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

-- 
carl.d.worth at intel.com
-------------- 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/20120316/3fcfa67a/attachment.pgp>