Closed Bug 1479136 Opened 7 years ago Closed 8 months ago

Lots of time in paint in a profile

Categories

(Core :: Graphics, enhancement, P3)

enhancement

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: zbraniecki, Unassigned)

References

Details

(Whiteboard: [gfx-noted])

A user on reddit reported Firefox to be slow with his (non-public) web application: https://www.reddit.com/r/webdev/comments/8xp608/google_chrome_devs_youre_really_starting_to_boil/e2hy8jo/ I asked for a profile and got two: 1) Fx 61: https://perf-html.io/public/165751270ab3df7941c7628b2847d5286c3e5c7e/calltree/?thread=0&threadOrder=0&v=3 2) Fx Nightly (63): https://perf-html.io/public/937dd22cb02008a404487c00b1b1a0f5e9213156/stack-chart/?thread=0&threadOrder=0&v=3 The procedure is: ``` That profile is a representation of the page loading, me scrolling down a few times, pausing for a few seconds, then scrolling back up. Thus, the first half represents brand new rows being processed and displayed, and the second half represents cached rows being displayed. When scrolling down (the first half of the profile), rows are being processed for the first time as they appear, and height measurements are being batched. Note how long my rendering logic takes and how long painting takes. When scrolling up, the row heights have already been caclulated and cached during the period where we were scrolling down, so no height measurments are taken, and thus no layouts are triggered directly from code. Note that my rendering logic is negligible (~5ms at the max), yet painting takes a whopping 52ms! ``` The experience is: ``` The performance in Chrome (even without any of those optimizations) is buttery smooth on even my largest monitor. Firefox, on the other hand, stutters like no tomorrow. Even Edge outperforms it! I've stared at the performance profiler for hours trying to shave off as much processing time as possible, but there's no way around it: the actual paint itself accounts for 30-40ms on average. What's going on here? ``` I asked on #perf and got: ``` aklotz> gandalf: (...) I see lots of time being spent in display list painting -> suggests gfx gandalf> aklotz: who could I NI in such a bug? aklotz> gandalf: No idea. jrmuizel maybe? ```
AS per aklotz' suggestion :)
Flags: needinfo?(jmuizelaar)
These profiles are missing a lot of information. Were they collected with Gecko profiler? They're missing C++ stacks. Without those it's hard to track down what's actually happening.
Flags: needinfo?(jmuizelaar)
These profiles were taken using Firefox's native profiler, then uploaded to perf-html.io as suggested by Zibi. This site might strip out some data. I'm not sure. I DID notice that the nightly build's profile was completely lacking information about Graphics performance even when viewed immediately within the native viewer, so perhaps that's a bug in nightly? I can upload some raw profiles if that would help. Is there a suggested file host I should use?
If you profile with the Gecko profiler add-on from here https://perf-html.io/ on Nightly and then use the share button the profiles should have all of the information.
Oh, that makes sense! That's why your profile looked so empty. You used the devtools profiler which only profiles the website. To get full profile out of Firefox (all the low level stuff that is happening when Firefox is rendering your website): 1) Open Firefox Nightly 2) Go to https://perf-html.io/ and download the addon 3) Restart the browser so that there is only one tab open 4) press ctrl+shift+1 (or cmd+shift+1 on mac) -> the icon of the profiler should turn blue 5) Open your website and for 4-5 seconds perform the action that is janky 6) press ctrl+shift+2 -> this should save your profile and open it in new tab 7) share that profile Thank you!
Flags: needinfo?(Samuel.Hodge)
Here's a profile I ran using Nightly: https://perfht.ml/2vfflT2
Flags: needinfo?(Samuel.Hodge)
That looks much better - and by that I mean worse, but for the better ;) Jeff - can you take a look at the new one? Seems like an awful lot time in `NtUserMsgWaitForMultipleObjectsEx`?
Flags: needinfo?(jmuizelaar)
It looks like you're using WebRender. Can you do a profile without WebRender? Does the page work better without WebRender?
Flags: needinfo?(jmuizelaar) → needinfo?(Samuel.Hodge)
Also, it looks like the performance problem on this page is caused by native themeing. I suspect this page has a lot of native looking controls. If you style your controls so that the OS style is not used it should run much faster.
Here is a new profile WITHOUT webrender: https://perfht.ml/2vkZJNN The native controls on the page would be checkboxes, inputs, and selects. I'll throw in some custom styles and re-run the profiler. Until then, hopefully the new profile above will help diagnose the underlyng issue.
Flags: needinfo?(Samuel.Hodge)
I should also mention that the page appears to render quicker with WebRender enabled.
Setting the NI on Samuel to get the outcome of custom styling.
Flags: needinfo?(Samuel.Hodge)
I actually don't think I'm able to do anything about the native theming. I added some borders and backgrounds to the <select> elements, but there's only so much I can do. There's no way to fully overwrite the CSS on a select. Same goes for checkboxes. I already had custom CSS applied to the text inputs, so that was never a factor. Unless you have some suggestions on what to do, I think the last profile is the best I can offer.
Flags: needinfo?(Samuel.Hodge)
Sorry for yet another double-post, but you should know that there are only ever about 20 rows visible at once, so that's 20 text inputs, checkboxes, and selects. And, I hate to make the comparison, but Chrome and Edge have no problem handling natively themed inputs.
> Unless you have some suggestions on what to do, I think the last profile is the best I can offer. Can you set border / background-color / color for all of your inputs manually? This should prevent any OS native styling. > And, I hate to make the comparison, but Chrome and Edge have no problem handling natively themed inputs. Don't feel bad about it. The beauty of having multiple engines is that every engine is faster in something and we all try to match or beat it. The end result is a performance race to the top :) IIRC Chrome does not do too much about native theming of inputs tho, so there may be an issue. On the other hand, if you're saying there's only 20 rows visible at once then it shouldn't be that much of a case - but maybe we're missing some caching and when you add new row we recalculate more than we have to? Once you set the CSS that I asked, if the performance is still the same (new profile pls!), we'll look for other causes.
I added border, background-color, and color styles on all form elements. Here's the new profile: https://perfht.ml/2M0apbJ
Thank you! Jeff - does it make it more actionable?
Flags: needinfo?(jmuizelaar)
Theming being slow is a known problem. That profile still has native theme drawing in it. (I'm not sure what css all needs to be set to make it better) We plan on redoing how widget themeing is done so that it isn't actually native but looks ok. (This is what Chrome and Edge do) If you turn on mozilla.widget.disable-native-theme it should improve the performance for you.
Depends on: 1288513
Flags: needinfo?(jmuizelaar)
Depends on: 1479640
I'm guessing "mozilla.widget.disable-native-theme" is a hidden flag I need to create in about:config? I went ahead and created the flag, set it to true, and ran the profiler: https://perfht.ml/2vsDO7F I admit it's difficult for me to parse through these profiles, but it looks like there is still a bottleneck.
The new profile has significantly reduced paint times. A big chunk of the remaining time is spent in restyle. I suspect we're flushing style more often than Chrome and Edge. Thoughts Emilio?
Flags: needinfo?(emilio)
A lot of the theming time is being spent allocating/deallocating the windows native surfaces. It's possible we could pool/atlas those in the short term to prevent some of that. We still have a few slow rasterizes in the profile from comment 19, mainly time spent blocking on the d2d lock. That's creating path builders (for complex clip in box shadow outer) and for initializing new d2d draw targets. Ryan, are there any plans to move those D2D operations onto the paint thread?
Flags: needinfo?(rhunt)
(In reply to Jeff Muizelaar [:jrmuizel] from comment #20) > The new profile has significantly reduced paint times. A big chunk of the > remaining time is spent in restyle. I suspect we're flushing style more > often than Chrome and Edge. Thoughts Emilio? Looks like we're restyling large parts (~600 elements) of the page over and over, but without access to the page it's hard to see what we could improve there... Would there be any chance of getting some kind of test-case or something, or a description of which kind of DOM, attribute and state changes happen on the page?
Flags: needinfo?(emilio)
I'll have to create a minimal test case, which may take some time. I can tell you that the elements are in a container that is position: sticky; which is likely what is not optimized very well. If I scroll fast enough, the edges of the container flicker, as if struggling to keep up with the scroll offset. Additionally, I use translations on the elements within the sticky container to fake mid-element scrolling. These translations are updated on scroll, but I cache my measurements, so these translations shouldn't be triggering layout.
Priority: -- → P3
Whiteboard: [gfx-noted]
I talked with Matt on IRC about moving D2D path creation to the paint thread. We don't have immediate plans to do this, but Bas wrote patches a while back to do this. I can't seem to find them though. I don't know how much work is required to land them.
Flags: needinfo?(rhunt)
Severity: normal → S3

Samuel, are you still experiencing this issue?

Depends on: 1381938
No longer depends on: 1288513
Flags: needinfo?(Samuel.Hodge)

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.

Flags: needinfo?(Samuel.Hodge)

This bug isn't really actionable without access to the website or a reduced test case. Additionally, the problems mentioned in comment 21 should be mitigated by bug 1697053.

Reporter, please file a new bug if you are still experiencing issues

Status: NEW → RESOLVED
Closed: 8 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.