-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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
Do not serialize on UI/Raster threads for Shell::OnCreatePlatformView #29145
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 Hixie on the #hackers channel in Chat. 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. |
The bot will recognize benchmark changes as having a test after flutter/cocoon#1392 |
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.
While it's easy to intuit why removing the latching would make this faster, this code at the intersection or application-lifecycle, shell-lifecycle, thread-merging, and, background GPU access has been the cause of significant instability in the engine in the past. For this reason, I don't think we should count on existing tests to verify correctness or count the benchmark as a test.
From the Discord thread, the following testing approach was discussed. Can we add a test for that instead?
"In shell_unittests, create a shell that calls OnPlatformViewCreated, invoke main
that calls back into native code to wait for a latch. This will block the UI thread.
Then call PlatformViewDestroyed and release the latch. In dart code,
the add a platform view and try to render a frame with it. See what happens?"
shell/common/shell_benchmarks.cc
Outdated
SkCanvas* CompositeEmbeddedView(int view_id) override { return &canvas_; } | ||
|
||
private: | ||
SkCanvas canvas_; |
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.
Here and elsewhere: Disallow copy and assign.
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.
Done
shell/common/shell.cc
Outdated
raster_task, should_post_raster_task, | ||
&latch // | ||
] { | ||
// TODO(dnfield): This probably isn't necessary. The engine should be able to |
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.
Nit: TODO(91717)
instead
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.
Done
shell/common/shell_benchmarks.cc
Outdated
// snapshot. | ||
fml::TaskRunner::RunNowOrPostTask( | ||
thread_host->ui_thread->GetTaskRunner(), | ||
[]() { std::this_thread::sleep_for(std::chrono::milliseconds(5)); }); |
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.
Please avoid magic timeouts.
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.
To elaborate on how to avoid magic timeouts, you could either setup a latch that gets signaled on the NotifyDestroyed
. That can be after the timing for the run has been paused if needed.
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 was thinking a latch wouldn't be great here because the benchmark wouldn't even work without my change, but I guess it's fine and I have to re-order the threading anyway because of a misuse of GetPlatformView
.
Per offline conversation, updating this PR to also have the |
Benchmark is just giving me lots of headaches, and I'm not sure how much value it has. I've added tests. I also removed the check about whether we need to post the raster task or not from |
@chinmaygarde - mind giving this another review? |
…flutter#29145) * Do not serialize on UI/Raster threads for Shell::OnCreatePlatformView
…formView (flutter#29145)" This reverts commit 7d03471.
…eatePlatformView (flutter#29145)"" This reverts commit 5c16f37.
…ll::OnCreatePlatformView (flutter#29145)""" This reverts commit 810fe7a.
Fixes flutter/flutter#91711
This patch shows a substantial improvement in
flutter_gallery__start_up
.I did two runs each with and without this patch:
I believe the existing tests are enough to cover the thread safety, particularly around the raster thread merging tests in shell_unittests.cc. I've added a shell_benchmark for this. Before this patch, the values locally for
host_profile
are:After,
In one internal application, the time for this call went from >130ms to <100us on the platform thread.