I have been given this unusual warning from Firefox. The positioning effect it refers to is a div
I rotate as a factor of the scroll height. I have never had any problems with it, but is this something I should be concerned about? Is there anyway to have such effects without this warning?
The JavaScript that demonstrates this issue is:
//Rotate gears in about section
$('.gear').css({
'transition': 'transform 1s ease-out',
'-webkit-transform': 'rotate(' + Math.round(wScroll / 2) + 'deg)',
'-moz-transform': 'rotate(' + Math.round(wScroll / 2) + 'deg)',
'-ms-transform': 'rotate(' + Math.round(wScroll / 2) + 'deg)',
'transform': 'rotate(' + Math.round(wScroll / 2) + 'deg)',
});
wScroll
is the current scroll height
the best solution is a switch and a timer i expose here the answer to solve the same error when you use "on scroll" , i suggest you to adapt my script to your needs! https://stackoverflow.com/a/57641938/5781320
I know that this question was asked some time ago, however, the performance issue still exists. Below is an alternative solution that does not rely upon a scrolling event listener. This minimises jank and lag caused by the separate scrolling thread common among web browsers, updating the css at regular intervals rather than when the window is scrolled. This means that the dev console warning will not display. I personally wouldn't be too worried about the warning or using scrolling events for small things like turning a gear or changing a css class, however, if the user experience directly relies upon the effect, it will destroy the usability of the page.
A working example can be used on my GitHub. I have tested it on Firefox, Chrome and Edge (works).
Other alternatives to avoiding the warning are to use css sticky elements or use the element.classList.add() and element.classList.remove() methods limnked to a window.onscroll event.
Note: Be careful about using css transitions where the length of the transition is longer than the interval at which the CSS style will be updated by the script (such as with scrolling event based changes). Webkit based browsers and EdgeHTML will behave in unexpected ways to this, usually staying in their initial position until the element stops being updated by the script. Unless this is the effect you were intending, in which case it doesn't work the same way in firefox.
Servo Webrender, when integrated into Firefox will solve these problems to an extent (or at least improve the performance quite considerably). Although there will still be other browsers to maintain compatibility with.
The warning, I think, goes on to say:
But in case that page is unclear, here's the gist of it.
The idea of "asynchronous panning" is this: when the page is scrolled, the browser calls your
scroll
handler, but it also asynchronously paints the page at the new scroll-point. This is done to make scrolling appear responsive (@ 60 FPS) even when the main thread is busy for more than 16ms.This means that the effects your handler implements are not guaranteed to be in sync with the current scrolling position. I.e. the scrolling is smooth, but
your divs rotate with a smaller FPS -- appearing janky, non-smooth.Update, missed thetransition
effect in your example -- the rotation itself will also be smooth, but it might start later than the page starts to scroll.I don't think you can implement the exact effect you have with the currently available technologies without having this problem.
example
(Note that to see the APZ in action, you need to be running the Firefox version with it enabled. In particular this requires Firefox to be running in a multiprocess ("e10s") mode, which is still not in the release builds at this time.)