flypig.co.uk

After some considerably thought about the various options and after trying to fix the rendering pipeline with minimal changes, I've decided to change tack today. There's so much code that's been removed from the GLScreenBuffer.h and GLSCreenBuffer.cpp files that I don't see any way to resurrect the functionality without moving large parts of the removed code back in again.

Now, ideally it would be possible to add this to the EmbedLite code, rather than the gecko code. But as a first step I'm going to try to add it back in just as it was before. Following that I can then look at re-architecting it to minimise the changes needed to the gecko code itself. It would be a shame to end up with a patch that essentially just reverts a whole load of changes from upstream, but if that's where we end up, but with a working offscreen renderer, then maybe that's what we'll have to have.

Over the last few days I've already made a few changes to the code, but ironically they've only so far been to the EmbedLite portion of the code. But they're all also aimed at getting the SwapChain object working correctly. If I'm now going to reverse the upstream changes to this particular pipeline, then the SwapChain will be lost (it might get restored later; let's see). So I don't need the changes I made any more.

$ git diff
diff --git a/embedding/embedlite/embedthread/EmbedLiteCompositorBridgeParent.cpp
           b/embedding/embedlite/embedthread/EmbedLiteCompositorBridgeParent.cpp
index 34cff71f6e07..82cdf357f926 100644
--- a/embedding/embedlite/embedthread/EmbedLiteCompositorBridgeParent.cpp
+++ b/embedding/embedlite/embedthread/EmbedLiteCompositorBridgeParent.cpp
@@ -109,6 +109,7 @@ EmbedLiteCompositorBridgeParent::PrepareOffscreen()
 
   GLContext* context = static_cast<CompositorOGL*>(state->mLayerManager->GetCompositor())->gl();
   NS_ENSURE_TRUE(context, );
+  bool initSwapChain = false;
 
   // TODO: The switch from GLSCreenBuffer to SwapChain needs completing
   // See: https://phabricator.services.mozilla.com/D75055
@@ -125,6 +126,7 @@ EmbedLiteCompositorBridgeParent::PrepareOffscreen()
 
     SwapChain* swapChain = context->GetSwapChain();
     if (swapChain == nullptr) {
+      initSwapChain = true;
       swapChain = new SwapChain();
       new SwapChainPresenter(*swapChain);
       context->mSwapChain.reset(swapChain);
@@ -133,6 +135,13 @@ EmbedLiteCompositorBridgeParent::PrepareOffscreen()
     if (factory) {
       swapChain->Morph(std::move(factory));
     }
+
+    if (initSwapChain) {
+      bool success = context->ResizeScreenBuffer(mEGLSurfaceSize);
+      if (!success) {
+          NS_WARNING("Failed to create SwapChain back buffer");
+      }
+    }
   }
 }
 
$ git status
On branch sailfishos-esr91
Your branch is up-to-date with 'origin/sailfishos-esr91'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
  (commit or discard the untracked or modified content in submodules)
        modified:   embedding/embedlite/embedthread/EmbedLiteCompositorBridgeParent.cpp
        modified:   gecko-dev (untracked content)

no changes added to commit (use "git add" and/or "git commit -a")
$ git checkout embedding/embedlite/embedthread/EmbedLiteCompositorBridgeParent.cpp
Updated 1 path from the index

As you can see, the changes weren't very major anyway. So I've started reconstructing the GlScreenBuffer code. It's actually quite extensive and there are a lot of edge cases related to the EGL code. It's going to take quite a few rounds of changes, failed compilations, following up on missing or changed code and then recompilations. Each of these takes quite a while, so I'm bracing myself for quite a long haul here.

I've made some changes, I'm going to set it to compile and see what errors come out. It's also time for my work day, so I'll return to this — and all of the errors that come out of it — later on this evening.

[...]

I'm back to looking at this again and it's time consider the errors that came out of the most recent partial build. They look a bit like this.

64:31.86 ${PROJECT}/gecko-dev/gfx/gl/GLScreenBuffer.h:98:60: error:
    ‘SurfaceCaps’ does not name a type; did you mean ‘SurfaceFactory’?
64:31.86    static UniquePtr<ReadBuffer> Create(GLContext* gl, const SurfaceCaps& caps,
64:31.86                                                             ^~~~~~~~~~~
64:31.86                                                             SurfaceFactory
64:31.88 ${PROJECT}/gecko-dev/gfx/gl/GLScreenBuffer.h:99:45:
    error: ‘GLFormats’ does not name a type; did you mean ‘eFormData’?
64:31.88                                        const GLFormats& formats,
64:31.88                                              ^~~~~~~~~
64:31.88                                              eFormData
[...]
64:32.20 ${PROJECT}/gecko-dev/gfx/gl/GLContext.h:3537:54:
    error: ‘SurfaceCaps’ does not name a type; did you mean ‘SurfaceFormat’?
64:32.20    bool InitOffscreen(const gfx::IntSize& size, const SurfaceCaps& caps);
64:32.20                                                       ^~~~~~~~~~~
64:32.20                                                       SurfaceFormat
64:32.23 ${PROJECT}/gecko-dev/gfx/gl/GLContext.h:3546:59:
    error: ‘SurfaceCaps’ does not name a type; did you mean ‘SurfaceFormat’?
64:32.24    bool CreateScreenBuffer(const gfx::IntSize& size, const SurfaceCaps& caps) {
64:32.24                                                            ^~~~~~~~~~~
64:32.24                                                            SurfaceFormat
[...]

There are, as you can see, many, many, many errors. For the rest of this evening my recipe will be this:

1. Build code.
2. Examine compile-time errors.
3. Fix the first one or two erros shown.
4. Go to step 1.

This would take an inordinate amount of time with a standard build, but thankfully I can do partial builds just of the gfx/gl code.

$ sfdk engine exec
$ sb2 -t SailfishOS-devel-aarch64.default
$ source `pwd`/obj-build-mer-qt-xr/rpm-shared.env
$ make -j1 -C obj-build-mer-qt-xr/gfx/gl/

Initially these partial builds were taking less than a second, with errors being hit almost immediately. Now after a couple of hours of fixing compile-time errors the builds are taking longer, maybe nearing ten seconds or so. That's how I'm judging success right now.

My guess is that it'll be a few days at least before I've got all of these errors resolved. I'll continue charting my progress with these diary entries of course, but they may be a little shorter than usual, since the last thing anyone wants to read about is this iterative build-check-fix churn.

At least it's quite fulfilling for me, gradually watching the errors seep away. It's mundane but fulfilling work, just a little laborious. Let's see how far I've got by the end of tomorrow.

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