Skip to content
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

Enable partial repaint for Android/OpenGL #29591

Merged
merged 6 commits into from Jan 20, 2022

Conversation

knopp
Copy link
Member

@knopp knopp commented Nov 8, 2021

Pre-launch Checklist

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • I read the Tree Hygiene wiki page, which explains my responsibilities.
  • I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
  • I listed at least one issue that this PR fixes in the description above.
  • I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt. See testing the engine for instructions on
    writing and running engine tests.
  • I updated/added relevant documentation (doc comments with ///).
  • I signed the CLA.
  • All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

@flutter-dashboard
Copy link

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.

@zanderso
Copy link
Member

Related flutter/flutter#33939

@CaseyHillers CaseyHillers changed the base branch from master to main November 15, 2021 18:12
@godofredoc godofredoc changed the base branch from master to main November 24, 2021 07:08
Copy link
Contributor

@iskakaushik iskakaushik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall the direction looks good. Can we add some unit tests to android_context_gl_unittests.cc? Looks like as of 20ec34e we not have the capacity to run these tests on Android host devices.

shell/platform/android/android_context_gl.cc Outdated Show resolved Hide resolved
shell/platform/android/android_context_gl.cc Outdated Show resolved Hide resolved
shell/platform/android/android_context_gl.cc Outdated Show resolved Hide resolved
shell/platform/android/android_context_gl.cc Outdated Show resolved Hide resolved
@@ -105,10 +106,119 @@ static bool TeardownContext(EGLDisplay display, EGLContext context) {
return true;
}

class AndroidEGLSurfaceDamage {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any reason this class is forward declared rather than have the definition in android_context_gl.h?

Copy link
Member Author

@knopp knopp Dec 5, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer not having to split it into header/implementation but don't have strong feelings about it, if you prefer the definition in header I can certainly do it.

shell/platform/android/android_context_gl.h Show resolved Hide resolved
Copy link
Contributor

@iskakaushik iskakaushik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did not mean to approve before. I think it's important to have unittests figured out.

@chinmaygarde
Copy link
Member

@iskakaushik was looking into gathering firm numbers on the effects of this patch in a large-ish application. Is there any progress to made here?

@chinmaygarde
Copy link
Member

@iskakaushik Were you able to gather the numbers?

@iskakaushik
Copy link
Contributor

I’ve been spending the last couple of weeks attempting to get better traces on why DRM wasn’t showing as much performance improvement on Android devices as it was for iOS. I wanted to summarize my findings so far.

In cases where there are transitions, having partial repaint enabled is causing significant performance regression on Android when testing on internal benchmarks.

Looking at Flutter Gallery Animations as an example in depth, I was able to see similar differences in performance, the key differences are:

Metric With DRM Without DRM
99th_percentile_frame_build_time_millis 22.891 18.006
99th_percentile_frame_rasterizer_time_millis 31.61 20.967
frame_count 1172 1232

The first theory I had was that maybe ComputeClipRect was the primary cause of this change, but on further examination, it looks like it isn’t the reason, it took < 500 us each frame on avg, but the difference was ~4 ms on avg for rasterization.

Taking a look further at the top causes of this regression, It seems to me that we might be using raster cache more effectively when DRM is not enabled. This is based on the counts in the table below. Also, the RasterCachePopulate seems to be taking more time with DRM enabled. I'm planning on taking a look at it: flutter/flutter#96310

count mean std min 25% 50% 75% max name
553 2425.951175 2248.075344 249 1491 1784 2127 17935 RasterCachePopulate_with_drm
572 862.4213287 737.8742595 75 515 662.5 844.25 8657 RasterCachePopulate_without_drm
2240 75.33482143 23.46672769 43 59 69 87 279 RasterCacheResult::draw_with_drm
3282 26.65051798 11.76175858 6 18 24 33 149 RasterCacheResult::draw_without_drm

I’ve gathered more metrics here that I plan on looking at once I figure out the raster cache issue. Most of the metrics are worse than without enabling DRM, but I'm only investigating the ones with significant differences as some of the others might be due to the environment as well.

These benchmarks were run on a Pixel 4 XL device. I ran the Flutter gallery transitions benchmarks. Command for reference is (working dir: flutter/dev/integration_tests/flutter_gallery):

flutter drive --local-engine android_profile --profile --trace-startup -t test_driver/transitions_perf.dart

@knopp, @chinmaygarde would appreciate any thoughts here as well.

Copy link
Contributor

@iskakaushik iskakaushik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@zanderso
Copy link
Member

Was the solution to flutter/flutter#96310 disabling on older devices?

@iskakaushik
Copy link
Contributor

@zanderso I wasn't able to consistently reproduce the regression on my Pixel 4 XL device, and did not see it on another device I own. I'm wondering if it is due to my setup / environment issues. The current plan is to land this patch and monitor the benchmarks to see if there are any noticeable regressions in the build/raster time or raster cache usage, in which case I plan on reverting the change.

Disabling on older devices is due to glitches caused by their implementations of the required OpenGL extensions. I will file an issue for this.

@zanderso
Copy link
Member

@gaaclarke this week's sheriff to keep an eye on SkiaPerf when this rolls into the framework.

@zanderso
Copy link
Member

FYI this landed in flutter/flutter in flutter/flutter#96941. So far no regressions or improvements flagged by SkiaPerf.

@fzyzcjy
Copy link
Contributor

fzyzcjy commented Feb 4, 2022

Interesting... So do you find out the actual cause why it does not have improvements? (The iOS pr sounds very performant)

@knopp
Copy link
Member Author

knopp commented Feb 4, 2022

Interesting... So do you find out the actual cause why it does not have improvements? (The iOS pr sounds very performant)

Partial repaint improves performance in very specific cases, where only small part of screen is being updated (i.e. spinner or a cursor). I don't think there are currently any benchmarks focusing on that.

I did submit a PR for one, but it got a bit stale.

@@ -105,10 +109,135 @@ static bool TeardownContext(EGLDisplay display, EGLContext context) {
return true;
}

class AndroidEGLSurfaceDamage {
public:
void init(EGLDisplay display, EGLContext context) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

context isn't used below. was the plan to use it in the future?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really. I think I just overlooked it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants