[RFC] Avoiding some of the globals in glretrace
Alex Tru
alxtry at gmail.com
Wed Jun 15 17:32:30 UTC 2016
Hi,
Thanks for the feedback.
I haven't actually touched glws_* stuff (only some helpers in glretrace_ws).
I agree that the whole thing looks complicated and not very
beneficial, but I'll try to explain why I did this in the first place.
Basically, what I was interested in -- was to reset globals like
"drawable_map" in glretrace_glx.
This one specifically was found to cause some problems (in
iterations). So either one hardly resets all such globals each
iteration (which is also quite complicated, since they are declared
static at the file namespace; this will basically be some sort of hack
-- like this one https://github.com/trtt/apitrace/commits/staticsfix);
or these variables can be put into new classes (that we can
instantiate where needed). Function callbacks retrace_* in glretrace_*
depend on these variables (drawable_map etc.), so they become
state-dependant and should also be put in that class. Thereafter we
have state-dependant callbacks, that's why std::function comes into
play.
Perhaps, there can be just something that we can do with those
globals, but I can't wrap my head around it.
Alex
2016-06-15 19:13 GMT+03:00 José Fonseca <jose.r.fonseca at gmail.com>:
> Hi,
>
> Having an ABC for glws_* sounds good. I actually have an unfinished branch
> to do something similar. I have to see what's best.
>
> But having an ABC for glretrace_* retrace_foo doesn't look right. It's a
> lot of complexity for no good benefit. The callback table is nothing more
> than a sorted map: no matter how many interations one does, it should always
> yield the same result. So I rather not have the complexity. Let's use
> some sort of once-init or singleton paradigm.
>
> I don't understand the benefit of using std::function.
>
> Jose
>
>
> On Tue, Jun 7, 2016 at 8:14 AM, Трухин А. <alxtry at gmail.com> wrote:
>>
>> Hello,
>>
>> A bit of testing profiling with several passes revealed that globals
>> indeed play a role in consistency of results. Though, the
>> discrepancies are minor -- looks like it affects only the very
>> beginning of the trace (I guess resetting visuals would be enough to
>> avoid this actually).
>>
>> Nevertheless, I decided to try and remove some of globals (in window
>> helpers and interfaces). I also think this can "improve" retracing
>> several files (in one run) and make code generally more portable.
>>
>> Link to the branch: https://github.com/trtt/apitrace/commits/rmglob
>>
>> Brief summary:
>> 1) Promote callbacks to std::function
>> 2) Wrap GL window system helpers in class
>> 3) Wrap glx, wgl etc. interfaces in classes (register callbacks with
>> std::bind to the class object)
>> 4) Instantiate Retracer object in the local scope of main loop
>> 5) Instantiate and delete all the above every loop iteration
>>
>> What do you think?
>> _______________________________________________
>> apitrace mailing list
>> apitrace at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/apitrace
>
>
More information about the apitrace
mailing list