[PATCH] Android: Port eglretracer for Android (v5)

Juha-Pekka Heikkilä juha-pekka.heikkila at linux.intel.com
Wed Sep 25 10:57:55 PDT 2013


Hi Alexander,

> Do you still pursue this work, and have you been able to resolve the
> segfaults
> with multiple surfaces?

Yes, I still look after this. The software 'as is' works for things I need
it for now. The problem with multiple surfaces I did not look into any
further, it is a problem coming from inside SurfaceFlinger. Basically the
problem is this:

sp<SurfaceComposerClient> client = new SurfaceComposerClient;
sp<SurfaceControl> control1 = client->createSurface( String8("surface"),
            width1, height1, PIXEL_FORMAT_RGB_888, 0 );
sp<SurfaceControl> control2 = client->createSurface( String8("surface"),
            width2, height2, PIXEL_FORMAT_RGB_888, 0 );

Here creating control2, which is the new surface, cause instability often
resulting in segfault. Touching any surface after creating more than one
surface will likely segfault. Even if control1 is destroyed before
creating control2 a likely result will be segfault. This cannot be dealt
inside Waffle in my opinion since creating two windows (which in Android
will be SurfaceControl object) one expect to get two windows thus it
should be somehow found a way around in glws_waffle.cpp


> Why did you decide to abort when shared contexts are encountered?  As I
> see
> there's no Android-specific code for that, it just uses the existing EGL
> code,
> so there shouldn't be a problem with passing the shared context similar to
> how
> glws_glx does that.  Am I missing something?

This being Android specific I don't remember ever seeing shared context in
use. I don't recall how the class inheritance went inside Dalvik but I
think only one thread was able to draw in Dalvik. Quick googling show
results where most people trying to use shared context on android hit a
dead end with EGL_BAD_ACCESS error. For these reasons I did not see shared
contexts as any kind of blocking issue on Android.

> I wasn't aware that Waffle provides FindWaffle.cmake itself.  In that
> case,
> apitrace should not try to roll its own; rather, the users should be
> advised
> to make it visible to cmake during apitrace's build process and supply
> flags
> pointing to the headers and the library.

FindWaffle.cmake which come with Waffle library does not work inside
Android tree. I don't remember what was the root cause why it was not made
to work in the first place. I think it was related to Waffle inside
Android being build as a part of the rest of the Android system. I guess I
could a bit later see if I can fix this for Android Waffle so there would
be also possibility to use FindWaffle.cmake which come with Waffle, so far
there was never a need for this.

/Juha-Pekka


More information about the apitrace mailing list