This is occurring sporadically with several sites, but is most consistently reproducible at https://addons.mozilla.org/en-US/mobile/ The page appears entirely black, with no content displayed. In some cases (e.g. at m.cnn.com), the content briefly flashes on the screen before disappearing, and reappears if the page is scrolled to the bottom. This seems to be a very recent regression, and indeed the issue does not occur when the patches from bug 660090 are backed out.
Unless Joe has an idea what's causing this I suggest we back them out until we can fix them up.
The problem turns out to be that in certain cases, the wrong internal format is used in fTexImage2D. This should be easy to fix -- patch coming soon.
Is it bug 661002 by any chance?
(In reply to comment #3) > Is it bug 661002 by any chance? It certainly seems related. What's happening is that with bug 660090, the constructor of TextureImageEGL makes a call to Resize(), that in turn calls fTexImage2D. The latter call is made under the assumption that the surface's format is mUpdateFormat. When this guess turns out to be wrong, we're in trouble. Specifically, we're running into a situation where mUpdateFormat is ARGB_32, but the surface passed to TextureImageEGL::DirectUpdate() is RGB16_565. At this point the texture has already been allocated with internal format LOCAL_GL_RGBA, but it should really be LOCAL_GL_RGB.
Created attachment 549532 [details] [diff] [review] Recover from incorrect guess of surface format Before calling UploadSurfaceToTexture, we check if our guess of the surface format turned out to be incorrect; if so, we ask UploadSurfaceToTexture to reallocate the texture (using the correct format).
This seems like it will happen fairly often on mobile, and probably isn't great for performance. Can we either improve our guessing logic, or defer the initial texture creation until we know the surface type?
Created attachment 550389 [details] [diff] [review] Defer allocation of textures This postpones the allocation of textures until the texture is about to be used. This is essentially a middle-ground between what was happening before bug 660090 landed (we were allocating textures too late, and hence running into incomplete framebuffer errors), and what is happening currently (we are allocating textures early and hence sometimes we don't choose the right internal format).
Comment on attachment 550389 [details] [diff] [review] Defer allocation of textures I'd r+ this twice if I could. :)
Nice! Lets get this landed :)