apitrace doesn't capture glEGLImage* calls?

José Fonseca jose.r.fonseca at gmail.com
Sat Nov 28 13:28:01 PST 2015


apitrace traces a single process, any surface that is shared with a
differente process -- be it X, another GL, etc -- won't be properly
captured, as all operations that happens to that surface on the other
process is never seen.

What apitrace has is a hack to
replace glEGLImageTargetTexture2DOES/glXBindTexImageEXT with a "fake"
glTexImage2D call.

So, that even though the external process operations are not captured, with
some luck, the pixels of that surface are there, so the final rendering
will look about the same.  With some luck.

How this affects or not the rendering depends on case by case.

I'm afraid this is a just a limitation of apitrace -- apitrace primary
focus is the debugging of "proper" OpenGL or OpenGL ES APIs.  Debugging of
EGL/GLX/WGL has never been  a high priority, and glretrace doesn't
failthfully retrace EGL/GLX/WGL  -- it emulates so traces can be portable
across OSes.

Jose

On Sat, Nov 28, 2015 at 2:23 PM, Divick Kishore <divick.kishore at gmail.com>
wrote:

> Hi,
>     it seems that apitrace doesn't seem to capture glEGLImage* calls
> in the trace. Since I am seeing some differences in the output from my
> application which renders to an offscreen surface via FBO vs the
> thumbnails generated by apitrace, I am curious to know if it doesn't
> capture the glEGLImage* calls the thumbnails, could the resulting
> output be different?
>
> Thanks,
> Divick
> _______________________________________________
> apitrace mailing list
> apitrace at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/apitrace
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20151128/73feb575/attachment.html>


More information about the apitrace mailing list