List items
Items from the current list are shown below.
Gecko
6 Jun 2024 : Day 255 #
It's day 0b011111111 today, or to put it another way, day (2^8 - 1). That means tomorrow is the big one. I'm certainly hoping I won't need until 2^9 before ESR 91 is released, which hopefully means this will be the last big one, numerical speaking, for this project.
A couple of months back Adam Pigg (piggz) claimed he suspected me of holding out on a solution:
The truth was that at that stage I wasn't at all convinced I'd be able to get the WebView working in time. Thankfully it is now working, in the nick of time as it turns out, but nevertheless the task isn't quite complete. Even once I've finalised this WebView patch, there'll still be more work to do in areas including video rendering, WebRTC videoconferencing, patch refactoring and a bunch of smaller glitches to iron out. So I'm sorry to say there's still no release on the horizon just yet. But as I hope is clear by now, I'm playing the long game. Not only am I committed to getting it finished, but I'm also doing my best to help ensure the process is as streamlined as possible for the future too. Hopefully, when it comes to the next release, things will be easier.
Before I get back to coding, I also need to give advance warning that I'll not be posting entries next week. Next week is Hackweek at work, which means a week long intensive coding session with my colleagues. There's a good chance that this won't leave much in the way of free-time for me to be working on Gecko. That'll be from Monday 10th June to Friday 14th June. I'll start up right back where I leave things off on the Saturday though.
Alright, now back to coding. Yesterday you'll recall I discovered a problem with WebGL rendering. I know this was working back in February because I demoed it at FOSDEM, but some change I've made between then and now has broken it.
Yesterday I recorded a couple of backtraces around the crash. My suspicion is that the problem relates to the recent changes to offscreen rendering.
To test this theory out I've created a new branch and rolled the project back a single commit to before I started making the WebView changes. The wonders of version control! During the day today I set it building a completely fresh set of RPM packages based on this slightly older version of the code.
That's a big help. With the two backtraces captured yesterday my plan is to compare the execution flow with the working version to see how they differ. Here's what I believe to be the equivalent backtrace:
Unfortunately after the build during the day I'm a bit short on time to delve deeper in to this now. But I'll pick this up again tomorrow to try to figure out what the difference is. Once I have that it will hopefully give a much clearer idea about how to fix the problem with my latest changeset. I can then roll back to my original commit, fix it, and... well, let's see.
If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.
A couple of months back Adam Pigg (piggz) claimed he suspected me of holding out on a solution:
[M]y theory is that its all working just fine, and he's just dragging it out to the big reveal on day 2^8 :)
The truth was that at that stage I wasn't at all convinced I'd be able to get the WebView working in time. Thankfully it is now working, in the nick of time as it turns out, but nevertheless the task isn't quite complete. Even once I've finalised this WebView patch, there'll still be more work to do in areas including video rendering, WebRTC videoconferencing, patch refactoring and a bunch of smaller glitches to iron out. So I'm sorry to say there's still no release on the horizon just yet. But as I hope is clear by now, I'm playing the long game. Not only am I committed to getting it finished, but I'm also doing my best to help ensure the process is as streamlined as possible for the future too. Hopefully, when it comes to the next release, things will be easier.
Before I get back to coding, I also need to give advance warning that I'll not be posting entries next week. Next week is Hackweek at work, which means a week long intensive coding session with my colleagues. There's a good chance that this won't leave much in the way of free-time for me to be working on Gecko. That'll be from Monday 10th June to Friday 14th June. I'll start up right back where I leave things off on the Saturday though.
Alright, now back to coding. Yesterday you'll recall I discovered a problem with WebGL rendering. I know this was working back in February because I demoed it at FOSDEM, but some change I've made between then and now has broken it.
Yesterday I recorded a couple of backtraces around the crash. My suspicion is that the problem relates to the recent changes to offscreen rendering.
To test this theory out I've created a new branch and rolled the project back a single commit to before I started making the WebView changes. The wonders of version control! During the day today I set it building a completely fresh set of RPM packages based on this slightly older version of the code.
$ cd gecko-dev $ git checkout -b temp $ git log FIREFOX_ESR_91_9_X_RELBRANCH_patches_temp --oneline -5 eb40ffd47432 (FIREFOX_ESR_91_9_X_RELBRANCH_patches_temp) Restore GLScreenBuffer and TextureImageEGL d3ba4df29a32 (HEAD -> temp) Restore NotifyDidPaint event and timers f55057391ac0 Prevent errors from DownloadPrompter eab04b8c0d80 Enable dconf c6ea49286566 (origin/FIREFOX_ESR_91_9_X_RELBRANCH_patches) Disable SessionStore functionality $ git reset --hard d3ba4df29a32d53c38c68e4512d1fa82073ecdf4 $ git log --oneline -4 d3ba4df29a32 (HEAD -> temp) Restore NotifyDidPaint event and timers f55057391ac0 Prevent errors from DownloadPrompter eab04b8c0d80 Enable dconf c6ea49286566 (origin/FIREFOX_ESR_91_9_X_RELBRANCH_patches) Disable SessionStore functionality $ cd .. $ sfdk build -d --with git_workaround [...]Testing these new packages this evening I find that WebGL is indeed working with this one-commit-older version. That narrows down the problem to somewhere in the most recent commit eb40ffd47432.
That's a big help. With the two backtraces captured yesterday my plan is to compare the execution flow with the working version to see how they differ. Here's what I believe to be the equivalent backtrace:
Thread 10 "GeckoWorkerThre" hit Breakpoint 2, mozilla::gl:: SharedSurface_Basic::SharedSurface_Basic (this=0x7f81347dc0, gl=0x7f815d82c0, size=..., hasAlpha=true, tex=1, ownsTex=true) at gfx/gl/SharedSurfaceGL.cpp:54 54 SharedSurface_Basic::SharedSurface_Basic(GLContext* gl, const IntSize& size,This leads us to the second backtraces for the ToSurfaceDescriptor conversion method:
Thread 8 "GeckoWorkerThre" hit Breakpoint 5, mozilla::gl:: SharedSurface_Basic::ToSurfaceDescriptor (this=0x7fc8d8c9f0) at gfx/gl/SharedSurfaceGL.cpp:31 31 Maybe<layers::SurfaceDescriptor> SharedSurface_Basic:: ToSurfaceDescriptor() { (gdb) bt #0 mozilla::gl::SharedSurface_Basic::ToSurfaceDescriptor (this=0x7fc8d8c9f0) at gfx/gl/SharedSurfaceGL.cpp:31 #1 0x0000007ff3694278 in mozilla::WebGLContext::GetFrontBuffer ( this=this@entry=0x7fc94b8d10, xrFb=<optimized out>, webvr=webvr@entry=false) at dom/canvas/WebGLContext.cpp:949 #2 0x0000007ff365c528 in mozilla::HostWebGLContext::GetFrontBuffer ( this=<optimized out>, xrFb=<optimized out>, webvr=false) at ${PROJECT}/obj-build-mer-qt-xr/dist/include/mozilla/RefPtr.h:280 #3 0x0000007ff365c5d8 in mozilla::ClientWebGLContext::GetFrontBuffer ( this=this@entry=0x7fc8b4a4b0, fb=fb@entry=0x0, vr=<optimized out>, vr@entry=false) at dom/canvas/ClientWebGLContext.cpp:373 #4 0x0000007ff29b2410 in mozilla::layers::ShareableCanvasRenderer::<lambda()>:: operator() (__closure=<synthetic pointer>) at gfx/layers/ShareableCanvasRenderer.cpp:148 #5 mozilla::layers::ShareableCanvasRenderer::UpdateCompositableClient ( this=0x7fc98a98e0) at gfx/layers/ShareableCanvasRenderer.cpp:195 #6 0x0000007ff29f1e10 in mozilla::layers::ClientCanvasLayer::RenderLayer ( this=0x7fc959bd60) at gfx/layers/client/ClientCanvasLayer.cpp:25 #7 0x0000007ff29f0f30 in mozilla::layers::ClientLayer::RenderLayerWithReadback (this=<optimized out>, aReadback=<optimized out>) at gfx/layers/client/ClientLayerManager.h:365 #8 0x0000007ff2a01054 in mozilla::layers::ClientContainerLayer::RenderLayer ( this=0x7fc9798e60) at gfx/layers/Layers.h:1051 #9 0x0000007ff29f0f30 in mozilla::layers::ClientLayer::RenderLayerWithReadback (this=<optimized out>, aReadback=<optimized out>) at gfx/layers/client/ClientLayerManager.h:365 #10 0x0000007ff2a01054 in mozilla::layers::ClientContainerLayer::RenderLayer ( this=0x7fc8d810f0) at gfx/layers/Layers.h:1051 #11 0x0000007ff29f0f30 in mozilla::layers::ClientLayer::RenderLayerWithReadback (this=<optimized out>, aReadback=<optimized out>) at gfx/layers/client/ClientLayerManager.h:365 #12 0x0000007ff2a01054 in mozilla::layers::ClientContainerLayer::RenderLayer ( this=0x7fc93748a0) at gfx/layers/Layers.h:1051 #13 0x0000007ff2a08270 in mozilla::layers::ClientLayerManager:: EndTransactionInternal (this=this@entry=0x7fc8b18a30, aCallback=aCallback@entry=0x7ff46a44d0 <mozilla::FrameLayerBuilder:: DrawPaintedLayer(mozilla::layers::PaintedLayer*, gfxContext*, mozilla::gfx:: IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx:: IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::layers:: DrawRegionClip, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, void*)>, aCallbackData=aCallbackData@entry=0x7fdf2dd268) at gfx/layers/client/ClientLayerManager.cpp:341 #14 0x0000007ff2a12be4 in mozilla::layers::ClientLayerManager::EndTransaction ( this=0x7fc8b18a30, aCallback=0x7ff46a44d0 <mozilla::FrameLayerBuilder::DrawPaintedLayer( mozilla::layers::PaintedLayer*, gfxContext*, mozilla::gfx:: IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx:: IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::layers:: DrawRegionClip, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, void*)>, aCallbackData=0x7fdf2dd268, aFlags=mozilla::layers:: LayerManager::END_DEFAULT) at gfx/layers/client/ClientLayerManager.cpp:397 #15 0x0000007ff46a18f0 in nsDisplayList::PaintRoot ( this=this@entry=0x7fdf2df078, aBuilder=aBuilder@entry=0x7fdf2dd268, aCtx=aCtx@entry=0x0, aFlags=aFlags@entry=13, aDisplayListBuildTime=...) at layout/painting/nsDisplayList.cpp:2622 #16 0x0000007ff442dc4c in nsLayoutUtils::PaintFrame ( aRenderingContext=aRenderingContext@entry=0x0, aFrame=aFrame@entry=0x7fc9362940, aDirtyRegion=..., aBackstop=aBackstop@entry=4294967295, aBuilderMode=aBuilderMode@entry=nsDisplayListBuilderMode::Painting, aFlags=aFlags@entry=(nsLayoutUtils::PaintFrameFlags::WidgetLayers | nsLayoutUtils::PaintFrameFlags::ExistingTransaction | nsLayoutUtils:: PaintFrameFlags::NoComposite)) at ${PROJECT}/obj-build-mer-qt-xr/dist/ include/mozilla/MaybeStorageBase.h:80 #17 0x0000007ff43b8340 in mozilla::PresShell::Paint ( this=this@entry=0x7fc92df890, aViewToPaint=aViewToPaint@entry=0x7fc8570b20, aDirtyRegion=..., aFlags=aFlags@entry=mozilla::PaintFlags::PaintLayers) at layout/base/PresShell.cpp:6400 #18 0x0000007ff41f0210 in nsViewManager::ProcessPendingUpdatesPaint ( this=this@entry=0x7fc8570ae0, aWidget=aWidget@entry=0x7fc8570ba0) at ${PROJECT}/obj-build-mer-qt-xr/dist/include/mozilla/gfx/RectAbsolute.h:43 #19 0x0000007ff41f05c4 in nsViewManager::ProcessPendingUpdatesForView ( this=this@entry=0x7fc8570ae0, aView=<optimized out>, aFlushDirtyRegion=aFlushDirtyRegion@entry=true) at view/nsViewManager.cpp:394 #20 0x0000007ff41f0bb4 in nsViewManager::ProcessPendingUpdates ( this=this@entry=0x7fc8570ae0) at view/nsViewManager.cpp:972 [...] #51 0x0000007fefbb189c in ?? () from /lib64/libc.so.6 (gdb)There's actually very little difference between these calls, as we can see if we look at just the first couple of frames of each next to each other:
#0 0x0000007ff28d1ca4 in mozilla::gl::SharedSurface_Basic::ToSurfaceDescriptor (this=<optimized out>) at gfx/gl/SharedSurfaceGL.cpp:38 #1 0x0000007ff36920a4 in mozilla::WebGLContext::GetFrontBuffer ( this=this@entry=0x7fc94889c0, xrFb=<optimized out>, webvr=webvr@entry=false) at dom/canvas/WebGLContext.cpp:949
#0 mozilla::gl::SharedSurface_Basic::ToSurfaceDescriptor (this=0x7fc8d8c9f0) at gfx/gl/SharedSurfaceGL.cpp:31 #1 0x0000007ff3694278 in mozilla::WebGLContext::GetFrontBuffer ( this=this@entry=0x7fc94b8d10, xrFb=<optimized out>, webvr=webvr@entry=false) at dom/canvas/WebGLContext.cpp:949The first of these is the broken version, while the second is working. In order to get a deeper understanding, I'm going to want to step through the code between here and the crash.
Unfortunately after the build during the day I'm a bit short on time to delve deeper in to this now. But I'll pick this up again tomorrow to try to figure out what the difference is. Once I have that it will hopefully give a much clearer idea about how to fix the problem with my latest changeset. I can then roll back to my original commit, fix it, and... well, let's see.
If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.
Comments
Uncover Disqus comments