[PATCH v4 19/19] egl: EGL image trace support

[Imre Deak]

On Sat, 2012-07-14 at 08:31 +0100, José Fonseca wrote:
> On Thu, Jun 14, 2012 at 4:55 PM, Imre Deak <imre.deak at intel.com> wrote:
> > Getting the dimension / format of EGL images is not straitghforward.
> > One way to get these would be through glGetTexLevelParameter, but it's
> > not supported by GLES. Another way is to attach the EGL image to a
> > renderbuffer and call glGetRenderbufferParameter on it, but at least
> > mesa doesn't support attaching images in RGBA_REV format. And that
> > format happens to be an important one in applications we care about
> > (like the Android browser). We could also check the parameters of the
> > underlying native buffer, but these are not exposed through any API (for
> > either Xpixmaps or Android native buffers)
> >
> > So the only way I found is to try a non-destructive glCopyTexSubImage2D
> > with sizes starting from GL_MAX_TEXTURE_SIZE down to 1 and determine the
> > correct size based on whether this returns an error or not.
> >
> > Signed-off-by: Imre Deak <imre.deak at intel.com>
> > ---
> >  helpers/eglsize.cpp       |  231 +++++++++++++++++++++++++++++++++++++++++++++
> >  helpers/eglsize.hpp       |   37 +++++++
> >  helpers/glsize.hpp        |    1 -
> >  retrace/glretrace_egl.cpp |   20 ++++
> >  specs/eglapi.py           |    4 +-
> >  specs/stdapi.py           |    4 +-
> 
> Imre,
> 
> Looks good overall, but I'd prefer that stdapi.py type system was not
> extended to support this. Overriding the behavior of EGLImageKHR
> serialization should be done in the egltrace.py/gltrace.py, e.g., by
> looking at the argument type, or funtion/arg name, in
> serializeArgValue() method. There are several other special cases are
> handled this way too.

Ok, I'll rework this based on the above and rebase/resend the patches
with the rest of the fixes.

--Imre