Blinking the caret in the Firefox location bar uses a lot more GPU power than in other browsers
Categories
(Core :: Graphics, defect)
Tracking
()
Performance Impact | medium |
People
(Reporter: florian, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: perf:resource-use, power, reproducible)
Here is a power profile comparing the GPU power used by blinking the cursor in Firefox (2.5-7.5s range) and Edge (11-22s range) : https://share.firefox.dev/3bL5wVO
And comparing Firefox (2.5-7.5s range) and Chrome (11.5-26.5s range) : https://share.firefox.dev/3yg3559
The sampling resolution is not good enough to say precisely how long the GPU remains awake, but in the Edge/Chrome case it seems to be between 5 and 10ms, and for Firefox it's at least 30ms.
Updated•2 years ago
|
Comment 1•2 years ago
|
||
Thanks, florian! These profiles are super neat! jrmuizel and I looked at them today, and we were wondering what was in the content area of each of the browsers during sampling. Were the windows of comparable size?
It might be useful to try to simplify and ensure that about:blank is loaded in all browsers, and that they're all the same size. We assume this is the case already, but want to double-check.
We're interested in more details: we need more information about what the GPU is doing when it's powering up. Can we capture a GPUView trace of each browser in this state? https://github.com/servo/webrender/wiki/Debugging-WebRender#gpuview
That will let us compare whether or not the GPU execution times match the power numbers that we're seeing.
Reporter | ||
Comment 2•2 years ago
|
||
(In reply to Mike Conley (:mconley) (:⚙️) from comment #1)
what was in the content area of each of the browsers during sampling.
From memory: Firefox had about:newtab (or about:home). Edge had about:blank (as the default homepage had lots of animations that had a massive power use). Chrome I don't remember, so it was likely the default home page.
Were the windows of comparable size?
Identical sizes, I used window snapping, Firefox had the right half of the screen, the other browser the left half.
We're interested in more details: we need more information about what the GPU is doing when it's powering up. Can we capture a GPUView trace of each browser in this state? https://github.com/servo/webrender/wiki/Debugging-WebRender#gpuview
That will let us compare whether or not the GPU execution times match the power numbers that we're seeing.
I might want to try, but I'm not sure I'll have time, and I'll be traveling during the next two weeks so I won't have access to my Windows machine.
My profiles are easy to reproduce, you just need a Windows 11 machine with an Intel CPU, and a recent Nighty with the "Power Use" feature checkbox checked on about:profiling.
Additional note: the GPU power used when blinking the caret on Edge/Chrome was similar to the GPU power used when blinking the caret in notepad.exe
Reporter | ||
Comment 3•2 years ago
|
||
(In reply to Florian Quèze [:florian] from comment #2)
(In reply to Mike Conley (:mconley) (:⚙️) from comment #1)
what was in the content area of each of the browsers during sampling.
From memory: Firefox had about:newtab (or about:home). Edge had about:blank (as the default homepage had lots of animations that had a massive power use). Chrome I don't remember, so it was likely the default home page.
Actually, I just found that Chrome was still running on the machine, so I can now say it was on about:blank too.
Comment 5•2 years ago
|
||
Not without doing a deep dive and seeing what code paths in terms of GPU, compositing, present dirty rects etc each browser is hitting.
Updated•2 years ago
|
Reporter | ||
Comment 6•2 years ago
|
||
Profile of power used when blinking the caret on Mac: https://share.firefox.dev/3cuUB2X
Comment 7•2 years ago
|
||
For what it's worth, I've looked at the blinking URL caret on the about:blank page with the "PAINT_DAMAGE_REGION" flag from gnome-shell's "looking glas" (alt+f2 -> "lg") enabled. I'm using the stable firefox tarball downloaded from mozilla.org (109.0.1).
The damage region appears to be larger than it needs to be. Sometimes it's the full browser window, sometimes about ~30% of the browser window, and sometimes just a rectangle of maybe 100x100 px around the caret. I couldn't figure out how to influence this behavior, it appeared to be pretty random. I don't think I can take a screenshot of the highlighted damage region.
Generally, when looking at / interacting with web pages, I feel like the damage region is unexpectedly large quite often. Like when repeatedly moving the mouse cursor over and away from a link with :hover style for text-decoration: underline, or a small animated gif in the corner of a website, the damage region is not just a rect around that link or the gif, but sometimes maybe ~30% of the browser window and sometimes even more than that. Maybe that's expected behavior because fine-grained tracking of damage regions is inefficient, I have no idea.
(Note that the Firefox build from Ubuntu's mozilla-team PPA appears to disable partial present completely and always updates the full window, even though about:support seems to indicate that it is enabled - I don't know about the snap package behavior in this regard)
Comment 8•2 years ago
|
||
Correction: I was actually using XWayland in that test, not native Wayland. When using native Wayland, the damage region appears to be the full window every time the caret blinks or anything on a web site changes. But this report is about Windows, so partial present probably works, like when using XWayland.
Description
•