Fenix uses 45% more energy when playing 720p video compared to Chrome
Categories
(Core :: Audio/Video: Playback, defect)
Tracking
()
People
(Reporter: bas.schouten, Unassigned)
References
(Depends on 1 open bug, Blocks 3 open bugs)
Details
On my Pixel 7. Playing 10 minutes of 720p video fullscreen uses 400mWh in Firefox vs 275mWh in Chrome.
Updated•10 months ago
|
Updated•10 months ago
|
Comment 1•10 months ago
|
||
As discussed on matrix the obvious difference is that chrome uses the SurfaceControl
API to provide video frames directly to surfaceflinger, which can usually by composited by hardwarecomposer directly: https://source.chromium.org/chromium/chromium/src/+/main:ui/gl/gl_surface_egl_surface_control.cc. Bas reports that disabling SurfaceControl in chrome reduced the gap in power consumption by 15pp (ie Firefox uses 30% more energy than chrome-with-surface-control-disabled)
Both Sotaro and I have in the past prototyped using SurfaceControl as a webrender native compositor, but found that the performance was dreadful. We believe this was due to webrender's native compositor API exposing each tile as a compositor surface, meaning we end up with dozens of SurfaceControl objects. For comparison, Chrome optionally uses one SurfaceControl as an "overlay plane" for video, and then always has a single SurfaceControl for the rest of the content. We should investigate whether we can do the same, and what effect that has on power consumption
Comment 2•9 months ago
|
||
The severity field is not set for this bug.
:jimm, could you have a look please?
For more information, please visit BugBot documentation.
![]() |
||
Updated•9 months ago
|
Comment 3•9 months ago
|
||
I couldn't get power profiling to work on my Pixel 8, but I captured some perfetto profiles of with the power rail probes enabled.
All on this video: https://m.youtube.com/watch?v=aqz-KE-bpKQ&pp=ygUOYmlnIGJ1Y2sgYnVubnk%3D at 720p in fullscreen.
Chrome results were consistent, but firefox seemed bimodal
As expected, Chrome uses significantly less GPU energy than Firefox. After disabling SurfaceControl, this is no longer the case.
One of the Firefox modes uses a lot more CPU than Chrome, but one uses less. Perhaps we were being throttled and the max clock speed had been reduced, I'll need to investigate that further.
Next steps are get traces with more information to explain Firefox's bimodality (confirm whether it's reduced clock speed or something else)
And capture some CPU profiles of both Firefox and Chrome
Comment 4•9 months ago
•
|
||
Fenix profile: https://share.firefox.dev/3UY0VUh
Chromium profile: https://share.firefox.dev/4bUKez1
Chromium with SurfaceControl disabled: https://share.firefox.dev/3UyHOPm
Some very high level analysis:
- Our renderer thread is a lot busier than their CompositorGpuTh
- Our WebContent and their CrRendererMain have a similar number of samples
- Both applications' MediaCodec_loop threads have a similar number of samples
- Our "Thread-33" (which is glean) is responsible for 4.4% of all our samples
- Our HwBinder thread is slightly busier than theirs. Seems we spend a decent chunk in
android::hardware::media::c2::V1_0::BnHwComponentListener::_hidl_onInputBuffersReleased
which they do not
Comment 5•9 months ago
|
||
Got the gecko power profiler working with help from Florian: https://share.firefox.dev/3UJmF5f
Description
•