RefreshDriver tick scheduled unnecessarily when style is changed during scroll event
Categories
(Core :: Layout, defect, P4)
Tracking
()
People
(Reporter: mstange, Unassigned)
Details
Sometimes we call EnsureTimerStarted from within a refresh tick. In some cases, this can schedule an extra tick even though all the necessary flushes will already happen during a later phase of the current tick.
For example: In a refresh tick, scroll events are fired before Styles are flushed. If, during the scroll event, style is changed, we know that those changes will be picked up by the style flush later in this tick.
But instead, we play it safe and schedule another tick after the current one.
Requesting extra ticks is usually harmless, but it will make a difference when we have bug 1675614: If no extra tick is requested, the next tick can be an early tick, and we have an opportunity for lower latency.
Testcase: attachment 8667908 [details]
Profile: https://share.firefox.dev/3k0ko0X
When you hover the RefreshDriverTick markers, you can see the cause callstacks. They show that the first tick was caused by the RequestContentRepaint IPC message, and the second tick was caused by a change to the backgroundPosition property, which happened inside the scroll event listener during the first tick.
To fix this, we should add an argument to EnsureTimerStarted with the needed refresh driver phase, and not schedule a tick if we're currently inside a refresh tick and the needed phase is still upcoming.
Reporter | ||
Comment 1•3 years ago
|
||
Here's a profile that shows two more issues of the same type: https://share.firefox.dev/3CAoQ0P
- Touching styles during a requestAnimationFrame callback
- Painting to a canvas during a requestAnimationFrame callback
(Hover over the RefreshDriverTick markers to see the trigger callstacks.)
Both of these things will be handled during a later phase of the current refresh driver tick, so there is no need to start the refresh driver timer for another tick.
Description
•