Gecko esr91 work (former "Flypig's gecko dev diary")

[flypig]

I’ve got a bit behind with the discussion here, but thanks for all the comments.

@tortoisedoc

is there a way to deploy the javascript as individual files?

You’re right, rebuilding just for JavaScript changes would be a real pain, but thankfully this bit, at least, can be streamlined. With JavaScript changes I transfer them directly over to the device (or sometimes even edit them on the device). Check out day 94 for a bit more on this.

@Valorsoguerriero97

Any news on the possibility to download and test ESR91 on SFOS devices?

Only that it’s on my to-do list. Once the WebView render is working, which I’m doing right now, it should be possible to install it without breaking the email client. So once I’m done with this I think it’d be worthwhile me spending some time to get a version others can really try out properly. I’ll post here when that’s available.

@PeperJohnny

Thanks for the detour with the avatars.

Thanks! I wasn’t sure whether to write about it, so glad to hear this. I’m not totally convinced this way was quicker than doing it by hand, but it was more fun

On the topic of user agents, I wasn’t aware of this aarch64/x86 hack Mozilla are using. That’s really interesting. It’s crazy that this stuff makes a difference, but given that it does, I personally think it’s worth following Mozilla’s lead. I’ll create an issue for it. Thanks for the discussion and links @direc85, @nephros.

[direc85]

I’m happy that the user agent string gets more thought, since it seems to be quite an important piece of the puzzle of getting more sites work properly… Hopefully with a good default user agent string the list of exceptions gets shorter too. And that’s where the community can really chip in!

Making a test release for the community is a nice idea indeed! I don’t remember if it’s just a JSON file on the disk or in a packaged file, but if the testers could change the content themselves, that would be even more helpful!

Thanks for making the avatar wall! I didn’t realize there are already so many contributors… It really is a community effort.

PS. The Rust 1.75 PR nudged forward a bit (compilation in OBS now works), we’re getting closer and closer of it getting merged.

[tortoisedoc]

@flypig came to mind, since theres mesa on sfos,
you can use thse env vars that might give more insight on the opengl side

https://docs.mesa3d.org/envvars.html

[tortoisedoc]

Ive got some though questions that came to mind today while reading the latest entry of the diary.
It seems we are at the detail stage, where things seem to be ok but really are not, and when the size of the effort becomes clear (massive).
Now dont take this as an offence (not intended to be!); Is @flypig the only one working on the browser at the moment ? Noone at jolla picking up the ball? If thats the case, what is Jolla’s comment on this? Id assume the browser is a key component of SFOS product…and as such an upgrade would be due more support from jolla side, one d expect…

[tortoisedoc]

@flypig good progress! \o/
It seems you have exited browser world and are stepping into wayland lands, thats a good sign, problems yes but somewhere else
you could try the WAYLAND_DEBUG=1 (or “all” iirc) to complete your logs with the wayland surface creation protocol (it might be qt-wayland doesnt support swapchains?). Its a fairly simple protocol.
It might make sense to run even an opengles, swap-chain based example to validate this hyphothesis…smaller to build and faster to work with!
Keep going @flypigg~~

[tomin]

The issue that @flypig is now trying to figure out sounds a bit like the one I had with Qt Scene Graph recently. I wasn’t properly releasing textures so it kept reserving dmabuf file descriptors and then eventually the app crashed because it run out of fds (or rather I think it tried to use fd > 1024 for something that’s not compatible with such “high” value). Anyway lsof -p output might be worth looking at.

[poetaster]

I’m just going to quote @flypig since it’s good to get some inspiration on a slog:

For those who are still following along, or just desperate to get your hands on a build to test, I appreciate it’s slow progress. But each fix is a fix that’s necessary and I remain confident that eventually all of the pieces will fall in to place. This is very definitely a marathon and not a sprint. An Odyssey not a citybreak. We’ll get there!

[tortoisedoc]

Rabbitholes be like loooooooooooooooooooong ones, right?

[poetaster]

Indeed! In my case, keeping me from doing sailfish work! Oh, no!

[d.geelen]

Seems @flypig finally managed to escape from a particularly deep one. Good to hear you fixed the freezing issue!

[poetaster]

Sheesh, was a bit of a read to catch up! And all for the difference in EGL and Egl

[tortoisedoc]

@flypig i suggest giving the LIB_GLDEBUG
/ MESA_DEBUG a try. They will generate alot of output but might highlight the failing function right away. Its time for the heavy weapons

[dcaliste]

Thinking about debugging GL code, maybe @flypig, you know or already uses this:

    glEnable(GL_DEBUG_OUTPUT);
    glDebugMessageCallback(_openGLMessage, 0);

where you can provide a function dealing with GL errors:

static void _openGLMessage(GLenum source _U_, GLenum type, GLuint id, GLenum severity,
                           GLsizei length _U_, const GLchar* message,
                           const void* userParam _U_)
{
  gboolean warn = TRUE;
  const char *ctype, *cseverity;
  switch (severity)
    {
    case GL_DEBUG_SEVERITY_LOW:
      cseverity = "LOW";
      break;
    case GL_DEBUG_SEVERITY_MEDIUM:
      cseverity = "MEDIUM";
      break;
    case GL_DEBUG_SEVERITY_HIGH:
      cseverity = "HIGH";
      break;
    default:
      cseverity = "UNKNOWN";
    }
  switch (type)
    {
    case GL_DEBUG_TYPE_ERROR:
      ctype = "ERROR";
      break;
    case GL_DEBUG_TYPE_DEPRECATED_BEHAVIOR:
      ctype = "DEPRECATION";
      break;
    case GL_DEBUG_TYPE_UNDEFINED_BEHAVIOR:
      ctype = "UNDEFINED";
      break;
    case GL_DEBUG_TYPE_PORTABILITY:
      ctype = "PORTABILITY";
      break;
    default:
      ctype = "OTHER";
      warn = FALSE;
    }
  if (warn)
    g_warning("GL CALLBACK: type = %s, severity = %s, id = %d, message = %s",
              ctype, cseverity, id, message);
  else
    g_debug("Visu OpenGL: type = %s, severity = %s, id = %d, message = %s",
            ctype, cseverity, id, message);
}

I’ve used it to partly understand what was wrong in my GL code. But maybe it’s not appropriated in your case if it’s a transfer issue between GPU and offscreen buffer… Good luck anyway !

[tortoisedoc]

If its an opengl transfer, it will show!

[tortoisedoc]

@flypigg about the misalligned texture;
two things can go wrong (assuming the data is correct in the texture) :

• alignment of data (start, stride)
• format of pixel (ARGB / RGBA etc)

Which one is the texture you are looking at configured with?

Is the image the same the browser would show? Which image are you displaying in the embedded view?

Just some small ideas, hth

[flypig]

Thanks for the input @tortoisedoc. I know what sort of image I’m asking for (RGBA in UNSIGNED_BYTE format). But whether that’s what’s being produced is less clear. Based on the code I expected it to be in the same format as is rendered to the screen, but that doesn’t seem to be the case after all

[tortoisedoc]

See where the glTexImage2d is used ?

https://registry.khronos.org/OpenGL-Refpages/es3.0/html/glTexImage2D.xhtml

that should give you an idea where the data comes from, maybe

[piggz]

@flypig can you post one of the texture files? when i was working on my libcamera app, I found a website that let you upload a raw image, enter the width/height and try different parameters until you got it to display correctly. Right now I cant remember what it was though, but i’ll keep looking!

[vige]

Basic image editors, i.e. gimp, can also open anything. I have used it succesfully in similar situations.

[tortoisedoc]

@flypig some more thoughts on the alignment / stride etc:

assuming the rendering logic being the same in both off-screen and on-screen;
the difference can be in the shaders used; ie the vertex format…
and Id believe the same image / website would render ok on the on-screen pipeline…
so perhaps comparing the initialization of the rendering pipelines might give some insights…no idea how easy that is on firefox tho…