[PATCH] tracedump: add --help and --function-histogram

Zack Rusin zack at kde.org
Sat Sep 10 07:24:57 PDT 2011


On Saturday, September 10, 2011 07:23:14 AM José Fonseca wrote:
> Furthermore the GUI already passes warnings/errors from glretrace. So
> passing GL misuse notices would be a natural extension.

This is not really what I was talking about. The usage of the passes should 
indeed be in glretrace but there are other parts of it. At the very least that 
includes getting the names of the passes, getting their descriptions, ability 
to disable them, using random combination of them. And yes, while it's 
possible that the gui could again call glretrace with some --show-passes and 
have glretrace again output some format that it can parse, it's getting harder 
and harder to do things in the gui to a point that warrants consideration or 
at least, like I said in the original tool, it should be done in a way that 
makes parsing of that stuff really easy.

> > Regarding a pass/hinting mechanism, sounds like exactly what I need, qt
> > already has a plugin api that you can use afaik, and the same plugins
> > can be "hand" loaded into tracedump as well later. I guess I don't have
> > any special input so I'll wait for you guys to tackle it.
> 
> I really don't wanna add Qt as dependency to any command line tool, as
> it raises the bar to build apitrace on Windows/MacOSX much higher, and
> while I use the Qt GUI a lot on Linux, I rarely use anything but
> glretrace on Windows/MacOSX.
> 
> I'm also not sure what benefit we would get from a plugin api that we
> don't get from an ordinary shared library with a clean interface.

I don't think that either plugins or a shared library make much sense here. 
The analysis passes will be for now internal anyway, we just need a way of 
disabling/enabling any combination of them. As to the Qt dependency, I don't 
think that this particular case is something that would sway us to include, of 
course I'm pro it anyway just because I prefer Qt containers to stl and we 
could reuse timers, threading and importantly translations and those would 
simply need thirdparty to contain qt/src/corelib/tools but I don't think it's 
important right now.

z


More information about the apitrace mailing list