This repository was archived by the owner on Feb 25, 2025. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am assuming ES 2.0 capability baselines for my review. But feel free to correct me.
I think I see the bug here. You were attempting to give a sized internal format to TexImage2D. That is only legal in OpenGL ES versions > 2.0.
But you don't check for the presence of the correct extension in
GetSupportedTextureFormat.GL_RGBA8on older ES versions requires OES_rgb8_rgba8.But, even if you did, there are other issues with this code. Because the presence
GL_BGRA8_EXTwill cause the internal format and the format you tell Flutter the texture is to be off (seeresult->open_gl.framebuffer.target = format_;). That is, you will always create an RGBA image but may tell Flutter the image is BGRA.I guess I would ask why you need to mess with any of the internal formats. Always assume the unsized GL_RGBA, get rid of
GetSupportedTextureFormatand theformat_ivar and give0as the internal format to Flutterresult->open_gl.framebuffer.target = 0;You delete a bunch of code and make things simpler. And the same code gets run on new and old versions of the platform making testing easier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rename GL_COLOR_ATTACHMENT0_EXT to GL_COLOR_ATTACHMENT0 from the non ext header. Its the same value but available in ES2.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I assume ES 2.0 compatibility. the BlitFramebuffer call will fail later because that isn't available in ES 2.0 without a compat shim. So maybe this will fix one issue for the user to run into another later on down the line.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for all the pointers!
From my understanding, we should have ES 3.0 capability baselines:
In other words,
CompositorOpenGL::CreateBackingStoreshould only be used if Direct3D 11 is available and ANGLE should have complete OpenGL ES 3.0 support.Interesting, let me try that! 👀
Two community members (here and here) reported that this patch fixed the issue. Thankfully, it looks like
glBlitFramebufferworks for them :)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is then hard to see why the user is running into the error. Do we have a dump of
DescriptionGLES::GetString?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chinmaygarde I tried this suggestion:
It looks like Skia wants us to specify an internal format: using framebuffer target
0causesSkSurfacecreation to fail when it validates the backend render target. Specifically,GrGLCaps::onAreColorTypeAndFormatCompatiblereturnsfalseas the format info forglFormatofkUnknownhas nofColorTypeInfos.Errors you get with this experiment...
Patch to test this suggestion...
Stack trace for the check that fails `SkSurface` validation...
Hm interesting. On all my devices, we do indeed tell Flutter the image is BGRA even though we create an RGBA image. This seems to magically work somehow... I'll try some more variants:
FYI, I had copied this logic from the Linux embedder (here and here).
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried more variants:
❌ 1. Always tell Flutter RGBA (since the images are always RGBA)
This does not pass Skia's color type validation as our
MakeSkSurfaceFromBackingStoregives SkiakN32_SkColorTypeas the color type, which is actuallykBGRA_8888_SkColorType. Do you know why we always usekN32_SkColorType? ShouldMakeSkSurfaceFromBackingStoredetect the color type from the framebuffer target?Patch...
Error logs...
2. ✅ Create a BGRA image (so that what we tell Flutter matches the image)
This experiment works on my machine!
Patch...
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From resources I found online, BGRA seems like a better default choice as the backing store format.
https://stackoverflow.com/questions/74924790/why-bgra-instead-of-rgba
https://learn.microsoft.com/en-us/previous-versions/windows/apps/hh465096(v=win.10)?redirectedfrom=MSDN
https://learn.microsoft.com/en-us/windows/win32/direct3d10/d3d10-graphics-programming-guide-d3d9-to-d3d10-considerations?redirectedfrom=MSDN#mapping-texture-formats
Flutter Windows requires Direct3D 11, otherwise it falls back to the software backend.