Accidentally saved.

First seen after WebKit commit 498a4606de7de467023bc567bbe1205b30d99613 (patch attached)

Adding Blink>Animation label because that vaguely looks like what the CL is changing.

Deleted: patch.diff 13.3 KB

patch.diff 13.3 KB Download

Also attaching before/after samples

Deleted: bad.mp4 789 KB

	bad.mp4 789 KB View Download

Deleted: good.mp4 382 KB

	good.mp4 382 KB View Download

Linux only or all desktop platforms?

Seems to be only affecting Linux

We should inspect about:tracing before and after the regression patch to work out what's changed.

Turns out that patch is from 2013, this affects Chrome 33.
The post repo merge commit hash is e3f4dd836fe661014aaca0772372274222c9c4fa.

I'm finding it difficult to build Chrome so far back in time to do basic investigation. Passing to commit author and reassigning as compositor animations as that is what the commit is dealing with.

Lowering priority as it's a very old regression that reportedly only affects Linux.

I had trouble building a checkout that old as well.

If you're still trying to build, apply the attached patch, do a gclient sync and try building again.  You might need to change webkit_rev in .DEPS.git

The change is more noticeable on a release build.

Deleted: deps.patch 2.2 KB

deps.patch 2.2 KB Download

I am skeptical that the suspected CL can cause such a regression.

The suspected CL [2] reverts [1] which was apparently  broken optimization. If I understand it correctly as a result of it, we would be compositing more often when there is an active opacity animation.

There does not seem to be any active animations when resizing the browser
window so I don't know how that can affect things. Removing the Internals>Compositing>Animations component.

I did test the resize behavior on latest stable on Linux. It is
very janky but looking at trace it is more related to heavy raster
which keeps GPU process busy. (If interested see attached traces). Issue 506300 is tracking fixing that.

Given that the only suspected CL is related to M33 and so far we have not been able to trace it, and the fact that we are tracking the linux resize
jank elsewhere I am going to close this issue. 


[1] original CL: https://codereview.chromium.org/63813004
[2] revert CL which is suspected:  https://codereview.chromium.org/101623002


 

Deleted: trace_chromium-resize-M66-issue-620471-with-gpudebug.json.gz 17.1 MB

trace_chromium-resize-M66-issue-620471-with-gpudebug.json.gz 17.1 MB Download