Open Bug 1646571 Opened 5 years ago Updated 10 months ago

Better performances when dev console is opened

Categories

(Core :: Panning and Zooming, defect)

Product:
Core
Component:
Panning and Zooming
Version:
77 Branch
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: georgebenson, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

Build a Vue.js app whee some CSS properties are changed on scroll event.

Actual results:

Open dev console enhance CSS properties change on scroll event performances.
See https://stackoverflow.com/questions/62357587/opening-firefoxs-dev-console-enhance-the-perf-of-a-css-properties-change for more explanation and https://codesandbox.io/s/eager-sun-b5zkr for an example.

Expected results:

Same performances when the dev console is closed

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Console
Product: Firefox → DevTools

Could you record a performance profile using profiler.firefox.com while it is slow and share the recording here (via the build-in share button)? More details are available at https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem .

Flags: needinfo?(georgebenson)

Here is the profile with dev console closed : https://share.firefox.dev/3ejQFya
Same thing with dev console opened : https://share.firefox.dev/3hG85qF
The screenshots of the first profile shows clearly how the sticky orange bar is flickering on scroll (while it's not in the second one)

Flags: needinfo?(georgebenson)

The severity field is not set for this bug.
:nchevobbe, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(nchevobbe)
Severity: -- → S4
Flags: needinfo?(nchevobbe)

Maybe APZ component works better for this as Console should not change performance.

Component: Console → Panning and Zooming
Product: DevTools → Core

This is probably related to the thing we do with disabling APZ when devtools is open, see https://bugzilla.mozilla.org/show_bug.cgi?id=1316318

Also if you open the devtools into a new window I think that might be a workaround. It used to be a workaround at some point but I haven't tried recently.

By APZ, you mean the smooth scrolling feature?
If so, it happens whether it is enabled or not.
Same result whether the dev console is in a separate window or not.

APZ refers to the asynchronous (compositor-based) scrolling. See https://hacks.mozilla.org/2016/02/smoother-scrolling-in-firefox-46-with-apz/ for an overview of what it is and how it works. Fundamentally what you're trying to do in your page (drive an animation in JS using the scroll event) is not guaranteed to be flicker-free with compositor-based scrolling. We certainly try to make the main-thread repaint fast enough so that it is flicker-free, but it can't be guaranteed. If you look in the devtools console for your test page, you'll see a message about scroll-linked effects and a link to the MDN page here - that's describing this problem as well.

When the devtools are opened it puts some anonymous overlay content on the browser window (like highlighters and stuff) which also don't work well with APZ, for the same reason (they are updated via scroll events). So to improve the experience there we disable APZ when devtools is open, which is why your page then magically starts working without flicker.

You can verify this by disabling APZ manually, by going to about:config and setting the layers.async-pan-zoom.enabled pref to false and restarting the browser. With that disabled your page should work without flicker, but this obviously is a non-default configuration that users won't have.

Ideally of course you would just the CSS position:sticky which we handle in the compositor as well, and then it would be flicker-free. If for some reason that doesn't give you your desired behaviour, then we need to make sure that the main-thread JS code you're running and subsequent repaint by the browser can run at 60 frames per second in order to avoid the flicker. From the profile you linked in comment 3 you can see the JS handler for the scroll event itself is easily taking 40ms or so (see for example the Running time (ms) column corresponding to the EventDispatcher::dispatch scroll row in this zoomed-in view of your profile). 40ms is already more than 2x the frame budget of 16ms that you need to reach 60 frames per second, and that doesn't include the time the browser needs to do the repaint afterwards.

So if you want to go this route you need to spend some time optimizing your scroll listener to run faster. If you think this is a defect in the Firefox JS engine for taking too long, we can move this bug to the JS engine component. But I suspect most likely your listener is trying to do too much work, just from looking at the JS stack in the profile.

Thank you very much for this information.
Unfortunately the architecture of the page does not allow me to use a position:sticky (the sticky element is par of container with no y scrollbar). Indeed the listener seems not to be optimized. Maybe I should try to rewrite it natively instead of using the vue.js shortcut.
I don't have the knowledge to be able to estimate if it's a defect in the JS engine of Firefox, but I could see that the animation is fluid under Chrome (not tested on other browsers).

I confirm that switching layers.async-pan-zoom.enabled to false solves the problem.
Of course optimization must be at the heart of web development. But the use of a framework like vue.js (which is far from being the slowest) makes it more difficult to make sure that this kind of script is well optimized.
After reading the article about APZ, I understand its interest but I find it a pity that it causes this kind of problem.

(In reply to georgebenson from comment #10)

I don't have the knowledge to be able to estimate if it's a defect in the JS engine of Firefox, but I could see that the animation is fluid under Chrome (not tested on other browsers).

If you can use the chrome devtools to profile the scroll event handler, and you observe that it is running in much less time than in Firefox (even though roughly the same code is running) then that's a pretty good indication that it might be a defect in Firefox's JS engine. That is certainly a possibility.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #9)

If you look in the devtools console for your test page, you'll see a message about scroll-linked effects and a link to the MDN page here - that's describing this problem as well.

Speaking of that, the message in question is not displayed because the function triggered by the scroll is only effective if the sticky element is visible, which is not the case by case at the beginning of the navigation.
It could be useful to display this message even in this case.

You need to log in before you can comment on or make changes to this bug.