New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 648502 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Jun 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Changing composited animation playbackRate on mousemove is janky

Project Member Reported by alancutter@chromium.org, Sep 20 2016

Issue description

Test case: https://rawgit.com/web-animations/web-animations-demos/5a79ea08465e356a55b10c7c2270ca0efa07374d/clouds/index.html

Repro steps:
Click and drag the mouse up and down.

Expected:
The clouds should smoothly change their playback rate.

Actual:
The clouds stop moving while the playback rate is changing.
 
Look at a trace on a pixel 2, I'm seeing a fair bit of time updating animation state (see attached image). The compositing update step is heavy, too.
annotated-trace.png
430 KB View Download

Comment 2 by suzyh@chromium.org, Sep 21 2016

Status: Available (was: Untriaged)
Components: -Blink>Animation Blink>HitTesting
Looking at the DevTools timeline I think I see clue about what the issue might be.

We appear to be spending an unnecessary amount of time updating our layers' hitbox information when the document body is the only thing with a registered event listener for mousemove.

We may also be letting input processing block rendering frames on time though that may just be due to the lengthy "Update Layer Tree" step causing us to go over our budget.
hittest.png
174 KB View Download
Cc: alancutter@chromium.org
Components: Blink>Input
Labels: -Performance -Pri-3 -Update-Monthly Pri-2
Created minimal repro with a single animation.
https://jsfiddle.net/m4oktd3o/

<!DOCTYPE html>
<style>
body {
  overflow: hidden;
  min-height: 100vh;
}
</style>
<body>
In Chrome this animation janks if you move the mouse after clicking but not before clicking.
<div id="target">Test</div>
</body>
<script>
var animation = target.animate({transform: ['none', 'translateX(100vw)']}, {duration: 1000, iterations: Infinity});
document.body.addEventListener('mousemove', function() {
  animation.playbackRate = 0.9 + 0.1 * Math.random();
});
</script>

Removing performance label as it appears to be a behavioural issue rather than not being able to meet frame deadlines.

What does clicking on the page do to cause this change in behaviour?
Components: -Blink>HitTesting
Status: Untriaged (was: Available)
In the original animation it janks just moving the mouse. I don't think the click is necessary.

Removing HitTest component for now. If the hit testing is the problem, please re-add the component. Marking Untriaged so that Input triages the bug.
Cc: dtapu...@chromium.org
I think #5 is correct. It janks for my on any mouse move for me. The odd think is that it is working fine on M55 and it bisect it to "RAF Aligned Input" [1] which makes sense as that limits how many mouse move is handled during a single frame.

It seems like mousemove can cause the frame to take longer and any subsequent mouse move during that time adds to the problem leading to very long frames. This gets fixed with RAF aligned input.

alancutter@ can you test with latest canary and see if this is good enough to close the bug?

[1] https://chromium.googlesource.com/chromium/src/+/4d208cf0fb7fcad671dcf97c4c9c95af05f1b666

Cc: majidvp@chromium.org
Interesting. I can't repro the jank on a Chromium build, only on official Chrome builds.
Tested both Chromium and google-chrome-unstable at 8d817067131214a7c5ea66b95b9aaa30f41f773f-refs/heads/master@{#428890} with the same set of flags.
This applies to both the cloud demo and minimal repro in #4.

Confirmed locally that r4d208cf0 (RAF Aligned Input) fixes the issue for local builds of Chromium. Could it be that this change doesn't affect official builds? I'm not familiar with fieldtrials.
Yup that is precisely it. There is a field trial setting for the chromium build. But doesn't get applied for official builds. 
In that case I can confirm that fixes this issue!
Is there another bug open to track shipping RAF Aligned Input that this bug can be blocked on?
We aren't certain that we will ever be able to ship it. We want to but it is experimental. But this is a good example of what it helps to improve in the web.


Is there any fix that you can do to improve the situation?


Owner: majidvp@chromium.org
Status: Assigned (was: Untriaged)
I can take a closer look at a few trace to see what might be the underlying cause.

One idea I have is that changing the animation rate is effectively canceling the existing animation on CC and replacing it with a new one. This may be a source of potential jank if we miss a frame here. Perhaps that can happen when we have multiple mousemove event in a frame which does not happen with RAF aligned input. Just a hypothesis.

BTW, how popular is this pattern of changing playRate in mousemove handler? Should this be a p3 instead of p2?
This came up in a demo intended to show off playback controls (see cloud demo in top post).

My guess is that it's quite rare that it would be used this way seriously in the wild though I'd expect people experimenting with the API could run into this while testing and view Chrome as unpolished.
Labels: Hotlist-Input-Dev M-60
Status: Fixed (was: Assigned)
Closing since we launched raf aligned mouse input in M60.

Sign in to add a comment