49.0.2623.110 (64-bit) Ubuntu also works fine

51.0.2700.0 dev-m
Bug still present

Chrome has updated on Ubuntu to 50.0.2661.75 and bug appears. Remind that in 48.0.2564.103 there was not this bug.

Tested this issue on Windows 7 using chrome latest Dev M53-53.0.2756.0 by following steps mentioned in the comment #0. Unable to observe any differences in animation while comparing the older version of chrome M49-49.0.2623.87 to latest Dev M53-53.0.2756.0.

enazarev@ - Is this issue still seen on latest Dev M53-53.0.2756.0 ? Could you please recheck this issue by creating a new profile under chrome settings with no other extensions except Sexy New Tab.

Thanks!

brajkumar@ - Hi. Thanks for respond.
Yes, the issue is still present on Windows 7 Chrome latest Dev M53-53.0.2756.0

Able to reproduce this issue on Windows 7, Ubuntu 14.04 and Mac OS 10.11.5 using chrome stable M51-51.0.2704.84. Observed some lag in the animation.

Bisect Information:
=====================
Good build: 51.0.2671.0 
Bad Build : 51.0.2673.0 

Change Log URL:
https://chromium.googlesource.com/chromium/src/+log/8762bdedaa3229fad50a5c4d9541e83462fb2b87..94326b75fc5b320ff478e82023c1c4296a83750e

From the above change log suspecting below change

Review URL: https://codereview.chromium.org/1768043002

dsansome@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks!

dsansome's patch changes a test only, so it is unlikely to be responsible. Alan, can you give this a quick pass? I think Update-monthly is appropriate because the bug reportedly first appeared in v50.

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to repro this without having to install the extension, open attached test.html case (created from jsfiddle) with the window maximised on a high DPI device. See screen cast for comparison of maximised vs non-maximised.

All the time seems to be spend in rasterising. The main thread is mostly idle and yet so few frames are put out for non-composited animations (like transform-origin). See timeline screenshot.

Deleted: test.html 4.0 KB

test.html 4.0 KB View Download

Deleted: jank.webm 997 KB

	jank.webm 997 KB View Download

Deleted: devtools.png 147 KB

	devtools.png 147 KB View Download

Given the regression range in comment #9, this change to CompositorAnimations looks entirely plausible, although it does seem to cause more content to be composited so on the face of it would be faster: https://chromium.googlesource.com/chromium/src/+/1c1129d2fd8c4728671cd4f611083de6557ac5af

Try reverting and seeing if it is to blame?

Could someone take a look at the suggestion in #15?

I built content_shell before and after https://chromium.googlesource.com/chromium/src/+/1c1129d2fd8c4728671cd4f611083de6557ac5af.

Before this patch the animations were not getting composited and the entire thing was slow. After the patch only the transform part of the animation got composited, the transform-origin (which affected the horizontal position) was running on the main thread and was slowed down by the cost of paint.
The reason it looks so janky is because the compositor animation is running at a higher frame rate, the juxtaposition of the two animations running out of sync on the same element is what makes it look bad.

That change was to fix a regression where not enough animations were being composited so what we see now is really not a regression, it would have behaved the same prior to the compositor animation regression.

There's little we can do on the animations side for this case other than pull composited animations down onto the main thread when other main thread animations are running. We already do this if the animations are part of the same @keyframes rule but not for transitions. I don't think making the same behaviour apply to transitions is desirable for most cases though.

Passing back to paint team to decide if they want to invest time towards reducing main thread paint costs for this scenario. Perhaps we can avoid repainting for subsequent frames?

Thanks for the work on narrowing down the cause. I don't think we have any immediate work in this area, although we are working to composite more layers for other reasons.

 suzyh@, hi
I am appreciate for your deep analyzis.

I doubt that would be fixed soon. So is there any way to refactor css rules to sync all of these running animations, compositions and so on to make it look preaty?

Thanks

I don't think there is any thing to do in paint for this bug. Sending
back to animations for the answer to question 19. If animations has nothing further that should be done, we should close the bug.

that sounds sad :(
I remeber there was a times it works fine. I listed previously good builds in starting post and comment 1

@19: I recommend animating the transform of a container element rather than margin-left to have the horizontal movement run on the compositor.
Note: Avoid using percentage units in your transform as those won't get composited (requires layout calculations).

On the topic of synchronising animations we ensure all property animations in @keyframes rules and element.animate() run on the same thread for synchronisation purposes (if any of them are main thread, all of them become main thread).
We could force the same behaviour for transitions that start at the same time however I don't think pulling things off the compositor would be desirable in most cases especially considering the default value of transition-property is "all".