Apitrace based frame retracer

[José Fonseca]

On Tue, Jun 9, 2015 at 1:16 AM, Mark Janes <mark.a.janes at intel.com> wrote:

> Hello José,
>
> Thanks for the helpful response.  I didn't know about the UBJSON work,
> and I agree with your point about the use of GL by QtQuick.
>
> I think the most sensible place to begin is by exposing the existing
> retrace functionality in a usable library.  I'd like to build up some
> compelling functionality before attempting to incorporate it in
> qapitrace.  If my work doesn't pan out, then you won't have spent much
> time reviewing my patches.
>
> I'll keep my work MIT licensed and attempt to follow the apitrace
> conventions, to reduce the amount of work required to bring it into
> apitrace.  And I'll keep a public clone of the work available on github
> as I make progress.
>
> The items I'd like to change in apitrace retrace:
>
>  - remove main routines from retrace libraries, so other main routines
>    can link against them.
>

This sounds ok.


>  - encapsulate global variables used by retrace functions in a "retrace
>    state" object that is passed to the generated functions.
>


This sounds good in theory (I wish we could do it) but awful complicated in
practice.

We have globals in GL, EGL, D3D8, D3D9, D3D10 specific code.  To move all
globals into an object, you basically need to include all headers for all
apis when defining that object.

And I can say this is impossible. Names will clash (particularly, D3D7,
D3D8 and D3D9 can't be included simultanouesly, as structures with the same
name and different definitions appear in them).

Jose
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20150626/c23966cc/attachment.html>