Apitrace based frame retracer

[Mark Janes]

José Fonseca <jose.r.fonseca at gmail.com> writes:

> 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).

Thanks for this tip.  I got most of the way through GL, but couldn't
find a way to handle the verbosity global, which is accessed from
everywhere.

I imagine there is a way to encapsulate these globals in derived
classes, but it's probably not worth the effort.