Delete Skia-specific performance overlay implementation #174682
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
Author
|
I'm expecting I may get golden failures during the testing. |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request simplifies the performance overlay implementation by removing the Skia-specific rendering path and exclusively using the DlStopwatchVisualizer. This is a great simplification that removes redundant code and, according to the description, improves performance. The changes are well-contained, and the unit tests have been updated to match the new implementation. I have one minor suggestion to address a potential compiler warning.
chinmaygarde
approved these changes
Sep 15, 2025
Member
|
Are the all the errors goldens related? |
Contributor
Author
|
They are related to the fact that I changed the algorithm to draw them more clearly (the most recent measurement had always been obscured by the cursor), so they are intentionally different. I just need to set aside time to reinstall my cloudtop so I can generate the associated new goldens and include them in the PR. Alternately, we can convert this test to use the Skia Gold mechanism so they can be approved from the PR. |
github-merge-queue bot
pushed a commit
that referenced
this pull request
Oct 2, 2025
(Essentially a re-issue of #174682 which ended up with broken Google Testing links) We had 2 different implementations of the rendering code for the performance overlay layer. The skia version used some skia-specific code to render the overlay incrementally into an offscreen surface and so we created a different implementation for Impeller that only uses standard rendering calls (and no surface cache). It turns out that the Impeller version was faster anyway even on Skia so it is a simple change to delete the old code and always use the new visualizer. The new visualizer reduces the time to render the graph from just under 1ms to about .1ms on Skia. The new visualizer takes .1ms longer to compute on the UI thread, but overall we save time between the 2 threads. The new visualizer is much faster on Impeller. Some work could be done to save some of that time on the UI thread by only incrementally updating the graph data, but for now we can take the ~.8-.9ms savings with just some deleted code.
Contributor
Author
|
Superseded by #176364 |
mboetger
pushed a commit
to mboetger/flutter
that referenced
this pull request
Oct 7, 2025
(Essentially a re-issue of flutter#174682 which ended up with broken Google Testing links) We had 2 different implementations of the rendering code for the performance overlay layer. The skia version used some skia-specific code to render the overlay incrementally into an offscreen surface and so we created a different implementation for Impeller that only uses standard rendering calls (and no surface cache). It turns out that the Impeller version was faster anyway even on Skia so it is a simple change to delete the old code and always use the new visualizer. The new visualizer reduces the time to render the graph from just under 1ms to about .1ms on Skia. The new visualizer takes .1ms longer to compute on the UI thread, but overall we save time between the 2 threads. The new visualizer is much faster on Impeller. Some work could be done to save some of that time on the UI thread by only incrementally updating the graph data, but for now we can take the ~.8-.9ms savings with just some deleted code.
okorohelijah
pushed a commit
to okorohelijah/flutter
that referenced
this pull request
Oct 7, 2025
(Essentially a re-issue of flutter#174682 which ended up with broken Google Testing links) We had 2 different implementations of the rendering code for the performance overlay layer. The skia version used some skia-specific code to render the overlay incrementally into an offscreen surface and so we created a different implementation for Impeller that only uses standard rendering calls (and no surface cache). It turns out that the Impeller version was faster anyway even on Skia so it is a simple change to delete the old code and always use the new visualizer. The new visualizer reduces the time to render the graph from just under 1ms to about .1ms on Skia. The new visualizer takes .1ms longer to compute on the UI thread, but overall we save time between the 2 threads. The new visualizer is much faster on Impeller. Some work could be done to save some of that time on the UI thread by only incrementally updating the graph data, but for now we can take the ~.8-.9ms savings with just some deleted code.
reidbaker
pushed a commit
to AbdeMohlbi/flutter
that referenced
this pull request
Dec 10, 2025
(Essentially a re-issue of flutter#174682 which ended up with broken Google Testing links) We had 2 different implementations of the rendering code for the performance overlay layer. The skia version used some skia-specific code to render the overlay incrementally into an offscreen surface and so we created a different implementation for Impeller that only uses standard rendering calls (and no surface cache). It turns out that the Impeller version was faster anyway even on Skia so it is a simple change to delete the old code and always use the new visualizer. The new visualizer reduces the time to render the graph from just under 1ms to about .1ms on Skia. The new visualizer takes .1ms longer to compute on the UI thread, but overall we save time between the 2 threads. The new visualizer is much faster on Impeller. Some work could be done to save some of that time on the UI thread by only incrementally updating the graph data, but for now we can take the ~.8-.9ms savings with just some deleted code.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
We had 2 different implementations of the rendering code for the performance overlay layer. The skia version used some skia-specific code to render the overlay incrementally into an offscreen surface and so we created a different implementation for Impeller that only uses standard rendering calls (and no surface cache). It turns out that the Impeller version was faster anyway even on Skia so it is a simple change to delete the old code and always use the new visualizer.
The new visualizer reduces the time to render the graph from just under 1ms to about .1ms on Skia.
The new visualizer takes .1ms longer to compute on the UI thread, but overall we save time between the 2 threads.
The new visualizer is much faster on Impeller.
Some work could be done to save some of that time on the UI thread by only incrementally updating the graph data, but for now we can take the ~.8-.9ms savings with just some deleted code.