List items
Items from the current list are shown below.
Blog
23 Mar 2024 : Day 194 #
Today I'm trying to narrow things down after reconfirming that when there's no SurfaceFactory_EGLImage the app doesn't seize up. I want to focus on two methods. First to check if anything is up with SurfaceFactory_EGLImage::Create(). Second I want to try disabling elements of SharedSurface_EGLImage::Create() in case that makes any difference. It's just a short one today, but still important tasks for helping get to the bottom of things.
First up SurfaceFactory_EGLImage::Create(). There's nothing to disable here (all it does is return the factory) but there are some input parameters to check. I added some debug print code for this:
Next up is SharedSurface_EGLImage::Create(). For the first check I've got it to return almost immediately with a null return value. This may or may not prevent the seizing up from happening. Either way it will be useful to know. If it does, then I'm focusing my intention in the correct place. If it doesn't I know I need to focus elsewhere.
The builds for this aren't taking the same seven hours that a full gecko builds, but they do still take tens of minutes. This seems to make me even more impatient. I think it's because 10 minutes is long enough to be noticeable, but not long enough that it's worth me context switching to some other task.
On copying over the library and executing the WebView app I find that this change has indeed stopped the app from seizing up. So this is excellent news. It means that tomorrow I can continue through the SharedSurface_EGLImage::Create() narrowing down where the problem starts.
If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.
First up SurfaceFactory_EGLImage::Create(). There's nothing to disable here (all it does is return the factory) but there are some input parameters to check. I added some debug print code for this:
if (HasEglImageExtensions(*gle)) { printf_stderr("RENDER: prodGL: %p\n", prodGL); printf_stderr("RENDER: caps: any %d, color %d, alpha %d, bpp16 %d, depth %d, stencil %d, premultAlpha %d, preserve %d\n", caps.any, caps.color, caps.alpha, caps.bpp16, caps.depth, caps.stencil, caps.premultAlpha, caps.preserve); printf_stderr("RENDER: allocator: %p\n", allocator.get()); printf_stderr("RENDER: flags: %#x\n", (uint32_t)flags); printf_stderr("RENDER: context: %p\n", context); // The surface allocator that we want to create this // for. May be null. RefPtr<layers::LayersIPCChannel> surfaceAllocator; ret.reset(new ptrT({prodGL, SharedSurfaceType::Basic, layers::TextureType:: Unknown, true}, caps, allocator, flags, context)); }On ESR 78 the values from this method are the following:
=============== Preparing offscreen rendering context =============== RENDER: prodGL: 0x7eac109140 RENDER: caps: any 0, color 1, alpha 0, bpp16 0, depth 0, stencil 0, premultAlpha 1, preserve 0 RENDER: allocator: (nil) RENDER: flags: 0x2 RENDER: context: 0x7eac004d50And the values in ESR 91 are identical, other than certain structures residing in different places in memory:
=============== Preparing offscreen rendering context =============== RENDER: prodGL: 0x7ed819aa50 RENDER: caps: any 0, color 1, alpha 0, bpp16 0, depth 0, stencil 0, premultAlpha 1, preserve 0 RENDER: allocator: (nil) RENDER: flags: 0x2 RENDER: context: 0x7ed8004be0I forgot to add caps.surfaceAllocator to this list, but using the debugger I was able to confirm that this is set to null in both cases.
Next up is SharedSurface_EGLImage::Create(). For the first check I've got it to return almost immediately with a null return value. This may or may not prevent the seizing up from happening. Either way it will be useful to know. If it does, then I'm focusing my intention in the correct place. If it doesn't I know I need to focus elsewhere.
The builds for this aren't taking the same seven hours that a full gecko builds, but they do still take tens of minutes. This seems to make me even more impatient. I think it's because 10 minutes is long enough to be noticeable, but not long enough that it's worth me context switching to some other task.
On copying over the library and executing the WebView app I find that this change has indeed stopped the app from seizing up. So this is excellent news. It means that tomorrow I can continue through the SharedSurface_EGLImage::Create() narrowing down where the problem starts.
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