[beta] Cherry pick fix GTK redraw call being called from non-GTK thread #173669
Conversation
gtk_widget_queue_draw is not thread-safe, call it from an idle callback. Fixes flutter#173447
|
This pull request was opened from and to a release candidate branch. This should only be done as part of the official Flutter release process. If you are attempting to make a regular contribution to the Flutter project, please close this PR and follow the instructions at Tree Hygiene for detailed instructions on contributing to Flutter. Reviewers: Use caution before merging pull requests to release branches. Ensure the proper procedure has been followed. |
github-actions
bot
added
engine
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request effectively resolves a critical threading issue by ensuring that the GTK redraw call is executed on the correct GTK thread, preventing potential application freezes. The change correctly uses g_idle_add to schedule the operation. Additionally, the refactoring consolidates the redraw logic with the first-frame signal emission, which is a nice improvement for code clarity. The fix is well-targeted and correct. I have one minor suggestion to fix a typo in a comment.
| // callback. | ||
| g_idle_add(first_frame_idle_cb, self); | ||
| } | ||
| // Perform the redraw in the GTK thead. |
robert-ancell
changed the title
camsim99
added
the
autosubmit
|
Thanks for the cherry picks @robert-ancell! |
auto-submit
bot
merged commit 780ac30
into
flutter:flutter-3.36-candidate.0
2 participants
Cherry pick of #173602
Impacted users: All Linux users of Flutter
Impact Description: Due to calling gtk_window_redraw on a Flutter thread a lock up may occur. The Flutter app will then become unresponsive.
Workaround: No workaround
Risk: Low - fix is to run the GTK call on the GTK thread which is what the correct behaviour should be.
Test coverage: Rendering covered by existing tests, use of thread not explicitly tested, but #173660 opened to add this in future.
Validation Steps: Run test program in #173447 which generates many frames and maximizes the chance of a lock up.