flypig.co.uk

As I mentioned a couple of days back, I'm taking part in a hackathon for my work during the next week, so I'm not planning to make any posts for the next five days. This coming Saturday I'll continue right back off where I leave off at the end of today though.

For today, I'm looking further into why WebGL might not be doing what it's supposed to be doing. So far I've found that there are two methods in my commit diff that get hit when executing the broken code. These are:

1. SurfaceFactory::SurfaceFactory()
2. TextureImageEGL::TextureImageEGL()

Looking at the code and observing the execution using the debugger I can see that the stack trace for the second of these includes TileGenFunc(), which calls TileGenFuncEGL() which then calls TextureImageEGL::TextureImageEGL(). And the flow is definitely being affected by what happens in TileGenFunc().

Here's the diff between the two versions:

 static already_AddRefed<TextureImage> TileGenFunc(
     GLContext* gl, const IntSize& aSize, TextureImage::ContentType 
    aContentType,
     TextureImage::Flags aFlags, TextureImage::ImageFormat aImageFormat) {
-  return CreateBasicTextureImage(gl, aSize, aContentType,
-                                 LOCAL_GL_CLAMP_TO_EDGE, aFlags);
+  switch (gl->GetContextType()) {
+    case GLContextType::EGL:
+      return TileGenFuncEGL(gl, aSize, aContentType, aFlags, aImageFormat);
+    default:
+      return CreateBasicTextureImage(gl, aSize, aContentType,
+                                     LOCAL_GL_CLAMP_TO_EDGE, aFlags);
+  }
 }

As we can see, the original version always calls CreateBasicTextureImage() in the original version, whereas in the new version there's a switch to contend with. That means that in the new version, rather than doing the same thing as the original it will instead on occasion call TileGenFuncEGL(). So this is clearly a candidate for where things are going wrong.

To see whether this is having an important effect I've amended the method so that it has the same approach as previously, by changing it to this:

$ git diff
diff --git a/gfx/gl/GLTextureImage.cpp b/gfx/gl/GLTextureImage.cpp
index c2def2dedb18..8152128bdc9c 100644
--- a/gfx/gl/GLTextureImage.cpp
+++ b/gfx/gl/GLTextureImage.cpp
@@ -47,6 +47,9 @@ already_AddRefed<TextureImage> CreateTextureImage(
 static already_AddRefed<TextureImage> TileGenFunc(
     GLContext* gl, const IntSize& aSize, TextureImage::ContentType 
    aContentType,
     TextureImage::Flags aFlags, TextureImage::ImageFormat aImageFormat) {
+  return CreateBasicTextureImage(gl, aSize, aContentType,
+                                 LOCAL_GL_CLAMP_TO_EDGE, aFlags);
+
   switch (gl->GetContextType()) {
     case GLContextType::EGL:
       return TileGenFuncEGL(gl, aSize, aContentType, aFlags, aImageFormat);

Now when this gets called, it will immediately call CreateBasicTextureImage() rather than going into the switch conditional. This isn't a long term solution, it's just a way for me to test things out.

Unfortunately though, rebuilding and executing this change gives me the same result as before, in that the WebGL is still not showing signs of life.

So it's back to the code again. There's also another important change in that in some cases in GLScreenBuffer I've switched use of mSwapChain for mScreen instead. The two have quite different characteristics, so I should try switching this back as well, for example like this:

 bool GLContext::ResizeScreenBuffer(const gfx::IntSize& size) {
   if (!IsOffscreenSizeAllowed(size)) return false;
 
-  return mScreen->Resize(size);
+  return mSwapChain->Resize(size);
 }

Now when I build and try this something different happens. Now the app crashes when it tries to render the WebGL. That's not a bad thing, because the debugger will tell me where the crash is taking place.

I'll need to investigate this further. Not today though as I'm out of time, and I won't be picking this up tomorrow either. Instead there will be the five-day pause I mentioned at the top of this post, but I'll be back to continue this where I've left it this coming Saturday.

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