Sounds like it was waiting for something other than the video plug-in's gl calls (maybe in the Android UI?) Unless there was some type of race-condition going on, where it ended up waiting for 2 or 3 frames to go by before it could update.
EGL provides a cross-platform abstraction for the GL state machine to bind to. It's mainly for coordinating GL rendering activities with the native windowing/GUI/compositing operations of the platform. For example, Windows operating systems need to coordinate the drawing of the 2D window frame and widgets with the GL rendering activities inside that frame. There are mixed mode operations going on, e.g. GDI and OpenGL, and EGL coordinates those operations.
What's a bit confusing in our case is the term 'native' in eglWaitNative. It doesn't mean the 'native' as in C++ vs. Java, but rather means 'native' as in the Android native drawing and compositing operations vs. GL based draw operations. The eglWait* functions are probably for apps where a lot of mixed-mode rendering occurs and must be coordinated, e.g. where one thread is drawing the GL stuff and another is updating the decor, overlays, etc. drawn using a different API. I think they are used in the SDL Android example code to guarantee compositing safety at the possible expense of performance. I.e. they erred on the side of caution, but I don't think the use is necessarily prescriptive.
In our case, that "other stuff" is indeed the Android OS, refreshing the Action/Menu bar, Navigation bar, context menus, and GameOverlay, all of which occurs on a different thread. But in our case, there's no need for them to be in perfect frame sync
as long as the GL surface never overdraws the "other stuff". That's a big assumption (see next paragraph) but for the sake of discussion assume that it holds. My guess is that the new Adreno chipsets have some additional optimizations that make it more lazy in refreshing the "other stuff". When Garrett enabled the "Show touches" option in the Android settings, that forced the chipset to refresh the "other stuff" at a higher rate and hence allowed the app to run at a higher FPS.
I'm not sure about earlier Android versions, but at least for the JellyBean devices tested here, the Android layout manager (via the 'merge' object) seems to be smart enough to keep the two layers separate and not allow GL to overdraw the "other stuff" even if they're updated at different rates. I'm not sure if all Android versions and chipsets have these smarts, though. The main regression I could imagine this introducing would be flickering of the GameOverlay, Action Bar, and in-game context menus. I think that's the main risk we should keep an eye out for.
Edit: One other piece of info:
eglWaitGL is functionally the same as calling
glFinish, which the official Khronos docs say
glFinish is NOT required before a call to eglSwapBuffers or glReadPixels. glFinish can take some time and for performance reasons it is best to use this function infrequently and only when necessary.
