flypig.co.uk

Yesterday I spent a lot of time using the debugger, stepping through the code to find out why the GLContext isn't being created successfully. Deep in the code I found that a call to fCheckFramebufferStatus() is returning with the following error:

GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT

The OpenGL docs told us that this is returned if the framebuffer doesn't have at least one image attached to it. That's a little surprising because just a few lines above where the check takes place we find the following line:

  gl->AttachBuffersToFB(colorTex, 0, 0, 0, fb, target);

Maybe I'm misunderstanding how frame buffer attachment is supposed to work, or maybe there's something wrong with either the buffer or framebuffer. Either way, something needs fixing.

I've read carefully through the code and compared it with the changes from the previous working version. The remaining changes can be categorised into a few related areas and it seems to me that any one of these could be causing the problem:

1. The compacted version of GLContextProvider::CreateOffscreen() (maybe I got something wrong when I merged the three methods into one?).
2. Removal of the Wayland integration.
3. Removal of raw_fBindFramebuffer().
4. Changes to the EGLDisplay flow.
5. Changes to the SharedSurface_Basic class.
6. Simplifications of the texture destruction flow.

I looked carefully through the methods I merged together and I didn't see anything that was missed or disordered. Reverting that would be a simple thing to check though. I also think it's unlikely to be the texture destruction flow as this won't happen until later.

I've decided to start by looking at the SharedSurface_Basic() changes. It looks like these are used before the failure occurs and are part of the same execution flow, so they would seem to be good candidates.

Thankfully git will do the hard work of restoring the previous versions of the relevant files, but I also want to keep a record of the changes I'm making in case they don't have any effect. In that case, I may well want to revert the changes I'm making now. So the following steps store a record of the current diff, then revert it.

$ git diff gfx/gl/SharedSurfaceGL.cpp gfx/gl/SharedSurfaceGL.h > ../../
    surface-factory-changes.diff
$ git checkout gfx/gl/SharedSurfaceGL.cpp
Updated 1 path from the index
$ git checkout gfx/gl/SharedSurfaceGL.h
Updated 1 path from the index

Note that I'm only changing two files here: SharedSurfaceGL.h and SharedSurfaceGL.cpp. I'm still trying to keep my changes as minimal as possible.

Having made these changes the partial build has gone through successfully. On testing it I discover two things:

1. When using the browser, general rendering works fine, but WebGL rendering now no longer works. It doesn't crash, just doesn't show the WebGL content on the page.
2. WebView behaviour has changed slightly, although not in a way that fixes it. The screen goes full black and the app hangs. This is reminiscent of the behaviour we saw back around Day 185.

It's worth noting that in that case the issue with the app hang eventually got fixed on Day 197 when we narrowed it down to an OpenGL texture that wasn't being deleted alongside its associated surface. Here's the change in code that was needed:

 SharedSurface_EGLImage::~SharedSurface_EGLImage() {
   const auto& gle = GLContextEGL::Cast(mDesc.gl);
   const auto& egl = gle->mEgl;
   egl->fDestroyImage(mImage);
 
   if (mSync) {
     // We can't call this unless we have the ext, but we will always have
     // the ext if we have something to destroy.
     egl->fDestroySync(mSync);
     mSync = 0;
   }
 
+  if (!mDesc.gl || !mDesc.gl->MakeCurrent()) return;
+
+  mDesc.gl->fDeleteTextures(1, &mProdTex);
+  mProdTex = 0;
 }

The only reason I'm mentioning this now is in case we need to make a similar fix again. But I don't have time to focus on it right now, so I'm just keeping a note of it in case it turns out to be helpful for later.

So this is the state of the latest build. What I need to do now is some debugging to find out why these two issues are happening. In particular I want to find out whether SharedSurface_Basic gets used during a WebGL render.

But to do that I'll need to run a full build. It's late now, so I can run the build overnight and let my laptop do the work while I sleep. That sounds like a good plan to me, so see you tomorrow!

If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.