-
Notifications
You must be signed in to change notification settings - Fork 6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor GL rendering to prepare for GTK4 #50754
Refactor GL rendering to prepare for GTK4 #50754
Conversation
It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact "@test-exemption-reviewer" in the #hackers channel in Chat (don't just cc them here, they won't see it! Use Discord!). If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix? Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
Questions for reviewers:
|
bcb2097
to
57a667d
Compare
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 looks good to me, but to be honest I don't know the answers to your questions: it does seem odd that we'd need to go down to shaders to define a rectangular texture blit, but I guess it also gives us lots of flexibility if we need more functionality later. As long as it doesn't incur a performance penalty, and isn't too complex to implement, I don't see a problem with it. |
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.
- Remove FlGLArea - we can just use GtkGLArea directly - Stop using gdk_cairo_draw_from_gl, it's not available in GTK4. - Rename FlRendererGL to FlRendererGdk, this was implying that FlRenderer could be something other than OpenGL which is not the case currently. - Remove unnecessary virtual methods in FlRenderer, just implement them as standard methods.
…d was having issues in the GTK4 branch
c5e3ebf
to
829ae5e
Compare
Thanks for the reviews! I'm going to have a few more people look this over / test this before landing it. |
test-exempt: code refactor with no semantic change |
From my recollection, Does Linux have to support GLES 2? I ask as Windows uses |
GTK is designed to work with GLES 2+. |
…144436) flutter/engine@7e8fefe...6f80444 2024-02-29 [email protected] [Impeller] use specific format for bootstrap texture. (flutter/engine#51082) 2024-02-29 [email protected] [Impeller] remove warning about device transient depth+stencil. (flutter/engine#51033) 2024-02-29 [email protected] Refactor GL rendering to prepare for GTK4 (flutter/engine#50754) 2024-02-29 [email protected] Reland "[skwasm] Clip pictures if they go beyond the bounds of the window." (flutter/engine#51077) 2024-02-29 [email protected] Revert "[macOS] Use CVDisplayLink to drive repaint (#49159)" (flutter/engine#51095) If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll Please CC [email protected],[email protected],[email protected] on the revert to ensure that a human is aware of the problem. To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose To report a problem with the AutoRoller itself, please file a bug: https://issues.skia.org/issues/new?component=1389291&template=1850622 Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md
…ontext Solved by having three contexts - one for GDK and two for Flutter. Regression introduced in flutter#50754 Fixes flutter/flutter#148653
…ontext (#53103) Fix rendering corruption by Flutter and GDK sharing the same OpenGL context Solved by having three contexts - one for GDK and two for Flutter. Regression introduced in #50754 Fixes flutter/flutter#148653
…ontext (flutter#53103) Fix rendering corruption by Flutter and GDK sharing the same OpenGL context Solved by having three contexts - one for GDK and two for Flutter. Regression introduced in flutter#50754 Fixes flutter/flutter#148653
GLArea.has-alpha defaults to false, which makes it impossible for a Flutter app to be transparent. The additional change to glClearColor is to prevent a black flash when the application starts, before Flutter widgets become visible. This will also affect applications that aren't transparent, by showing the default GTK background color instead of black. This will not make the window transparent, because the developer currently has to add some code to their `linux/my_application.cc` to support transparency. Fixes flutter/flutter#152154 Transparent windows were possible before #50754. Would it be ok to add a test for this to prevent breaking transparency again in the future? [C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Refactor GL rendering to prepare for GTK4
Related: flutter/flutter#143408