Removing `apitrace trim-auto`

[José Fonseca]

Hi,

In sake of shrinking apitrace code base and keeping things maintainable I
plan to remove the `apitrace trim-auto` functionality.

trim-auto was added in 2013 by Carl Worth, and is capable of trimming
frames for simple traces, but it hasn't been maintained since, and
generalising to complex traces is IMO an almost vertical uphill battle.
>From what I gather from several bug reports, I'm personally not aware of
users being actually able to use this in practice as it stands.

Furthermore, I think that any attempt to "state tracking" in apitrace is
doomed to failure, particularly with the OpenGL API.  This is because
OpenGL API is mish mash of inconsistent extensions and it would require an
army of developers to pull it off, and neither will change in the
foreseeable future.  In fact, there are good chances that OpenGL is
destined to be a legacy API and attracts less and less mind share.

So, yes, while having Apitrace recording/replaying the all calls from the
very start is admittedly very dumb and slow, it's something that is both
*reliable* and *simple*.  And that's good enough for me, and for a lot of
people I suspect.  At any rate, it trumps complex and unreliable all the
time.

That said, if watching glretrace to replay every call from scratch for
every state lookup is too much to bear, then the suggestion of
https://github.com/janesma/apitrace/wiki/frameretrace-branch of making
glretrace sort of a daemon that keeps looping the calls withing a frame of
interest seems a much better compromise.  That should work a lot of the
time, and it's not really that complex, since there's no need for tracking
any state other than the frame boundaries.

So I'll yank this out.  If anybody has any concern or has been using this
functionality with success please do let me know.

Jose
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/apitrace/attachments/20170407/fff4b341/attachment.html>