Gecko-dev Diary
Starting in August 2023 I'll be upgrading the Sailfish OS browser from Gecko version ESR 78 to ESR 91. This page catalogues my progress.
Latest code changes are in the gecko-dev sailfishos-esr91 branch.
There is an index of all posts in case you want to jump to a particular day.
Click the icon for the Gecko-dev Diary RSS feed.
Gecko
5 most recent items
19 May 2024 : Day 237 #
I was easing myself gently back into Gecko development yesterday with a quick look over some of the work that others in the Sailfish community have been doing while I've been having a break, related to deciphering the messed up textures that are coming out of the render surface.
Today I'm back looking at the code in earnest. And it's been a fruitful process. My starting point has been to take a look not at the Gecko code, but from the other end: starting with QtMozEmbed and sailfish-components-webview. Taking things easy, I'm just browsing through the code, trying to find where the Surface, as used by Gecko, connects with the texture rendered to the screen by the WebView. If I can figure that out I'll feel like I'm on solid ground.
It looks like a key piece of the puzzle happens in QMozExtTexture::updateTexture(). For example, on ESR 78, when rendering is taking place, the method gets hit often. So often that it appears to be every frame:
This isn't something that's come up before. Until now I've focused almost exclusively on getting the texture rendered to at the other end. But it looks now like the QtMozEmbed code is failing somewhere; the render update isn't being called. Just to be clear though, this isn't due to any change that I've made in QtMozEmbed. At least that seems unlikely at any rate, given I've not made an notable changes to these parts of the code.
More likely, some part of the initialisation process in the Gecko code is failing, or not happening as it should. Something like that could well lead to a situation where the render update doesn't get called. For example, it could be that the texture is never set as part of the Qt Scene Graph. But that's speculation, it could be all sorts of things.
I'm rather excited by this. Maybe this is the key problem we've been searching for? But I don't want to go too far today while I'm still getting myself up to speed with things. So I'll continue looking in to this further tomorrow.
Also worth mentioning is that tomorrow is Jolla Love Day 2. I'm excited to find out what Jolla have in store for us and while I won't be able to attend in-person, I'll definitely be there both online and in spirit!
If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.
Today I'm back looking at the code in earnest. And it's been a fruitful process. My starting point has been to take a look not at the Gecko code, but from the other end: starting with QtMozEmbed and sailfish-components-webview. Taking things easy, I'm just browsing through the code, trying to find where the Surface, as used by Gecko, connects with the texture rendered to the screen by the WebView. If I can figure that out I'll feel like I'm on solid ground.
It looks like a key piece of the puzzle happens in QMozExtTexture::updateTexture(). For example, on ESR 78, when rendering is taking place, the method gets hit often. So often that it appears to be every frame:
Thread 9 "QSGRenderThread" hit Breakpoint 1, QMozExtTexture::
updateTexture (this=0x7f90024e30) at qmozexttexture.cpp:64
64 {
(gdb) bt
#0 QMozExtTexture::updateTexture (this=0x7f90024e30) at qmozexttexture.cpp:64
#1 0x0000007fbfc04f18 in MozMaterialNode::preprocess (this=0x7f9001ef60) at
qmozextmaterialnode.cpp:81
#2 0x0000007fbf8f0c44 in QSGRenderer::preprocess() () from /usr/lib64/
libQt5Quick.so.5
#3 0x0000007fbf8f0e5c in QSGRenderer::renderScene(QSGBindable const&) () from /
usr/lib64/libQt5Quick.so.5
#4 0x0000007fbf8f14c0 in QSGRenderer::renderScene(unsigned int) () from /usr/
lib64/libQt5Quick.so.5
#5 0x0000007fbf8ffe58 in QSGRenderContext::renderNextFrame(QSGRenderer*,
unsigned int) () from /usr/lib64/libQt5Quick.so.5
#6 0x0000007fbf9429d0 in QQuickWindowPrivate::renderSceneGraph(QSize const&) (
) from /usr/lib64/libQt5Quick.so.5
#7 0x0000007fbf916c04 in ?? () from /usr/lib64/libQt5Quick.so.5
#8 0x0000007fbf91cc10 in ?? () from /usr/lib64/libQt5Quick.so.5
#9 0x0000007fbea290e8 in ?? () from /usr/lib64/libQt5Core.so.5
#10 0x0000007fb74b0a4c in start_thread (arg=0x7fffffe9bf) at pthread_create.c:
479
#11 0x0000007fbe70b89c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/
clone.S:78
This contrasts with the ESR 91 build, where the same breakpoint is never hit. I placed a breakpoint on all of the updateTexture() methods just to be sure:
Num Disp Enb Address What 3 keep y <MULTIPLE> 3.1 y 0x07ff7b64ba4 <QSGDistanceFieldGlyphCache::updateTexture()@plt+4> 3.2 y 0x07ff7b64d64 <QSGDefaultPainterNode::updateTexture()@plt+4> 3.3 y 0x07ff7bf071c <QSGDefaultPainterNode::updateTexture()+20> 3.4 y 0x07ff7bf5230 <QSGDistanceFieldGlyphCache::updateTexture()+24> 3.5 y 0x07ff7c1babc <QSGDefaultLayer::updateTexture()+12> 3.6 y 0x07ff7ef846c <QMozExtTexture::updateTexture()+20>The fact there are hits for ESR 78, but not for ESR 91, is definitely of interest.
This isn't something that's come up before. Until now I've focused almost exclusively on getting the texture rendered to at the other end. But it looks now like the QtMozEmbed code is failing somewhere; the render update isn't being called. Just to be clear though, this isn't due to any change that I've made in QtMozEmbed. At least that seems unlikely at any rate, given I've not made an notable changes to these parts of the code.
More likely, some part of the initialisation process in the Gecko code is failing, or not happening as it should. Something like that could well lead to a situation where the render update doesn't get called. For example, it could be that the texture is never set as part of the Qt Scene Graph. But that's speculation, it could be all sorts of things.
I'm rather excited by this. Maybe this is the key problem we've been searching for? But I don't want to go too far today while I'm still getting myself up to speed with things. So I'll continue looking in to this further tomorrow.
Also worth mentioning is that tomorrow is Jolla Love Day 2. I'm excited to find out what Jolla have in store for us and while I won't be able to attend in-person, I'll definitely be there both online and in spirit!
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