Per-surface calls list

[José Fonseca]

On Fri, Apr 12, 2013 at 8:36 PM, Eugene Velesevich
<eugvelesevich at gmail.com> wrote:
> 2013/3/27 José Fonseca <jose.r.fonseca at gmail.com>
>>
>> The proper fix however requires a deeper change in qapitrace -- for
>> multithreaded apps, frame start/end should be tracked per thread, and
>> not per process.
>>
>> Jose
>
> Hello again,
>
> For the purpose of trace visualization in QApitrace, I think it is better to
> track calls and frames per drawable (not per context or per thread).

There will always be things that don't fit the norm. So instead of
choosing frames vs drawable vs etc, I think that we should add
multiple (or switchable) views to the GUI.

That is, we should be able to show the same trace, on multiple
windows, some filtered by thread, others by context, others by frame,
others by drawable.

This would mitigate the issues you point out below -- when the data
doesn't view a certain view, the the user should be able to switch to
a more natural view.

For this to work well, we really need a layer below trace::Parser that
does proper LRU caching, any call, instead of frame chunks at a time..

> I have a patch implementing per-drawable call lists in QApitrace (except for
> DirectX), however there are the following concerns, and I'd appreciate your
> advice.
>
> 1.  I'm afraid one cannot track DirectX calls in the same way, since it is
> an object-oriented API and some functions don't relate to a context object.
>
> 2.  A context bound to drawable B could have been previously modified by GL
> calls (set shaders, etc) while bound to some other drawable A. In that case, a
> user will not see those calls in drawable B call list and will need to find
> them in call lists related to other drawables.
>
> 3.  Modification of profiling gui will be required. I guess individual
> timelines are required for every drawable.

Jose