New issue
Advanced search Search tips

Issue 670509 link

Starred by 2 users
Status: Duplicate
Merged: issue 678432
Owner:
enne@chromium.org
Closed: Jan 2017
Cc:
danakj@chromium.org
flackr@chromium.org
weiliangc@chromium.org
vmp...@chromium.org
ajuma@chromium.org
enne@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 1
Type: Bug-Regression



Sign in to add a comment

3d Animation freezes compositor

Project Member Reported by petermayo@chromium.org, Dec 2 2016 
on tip of tree  only
stable works

only repro'd on linux other platforms may or may not be affected

steps: load attached file, notice animation stops after 1/10 to 8 seconds.

expected: animation continues to 100s

This is a sub case of bug 626095

The key thing that stops it is an animation around a particular value of a 3d transform for a polygon that doesn't actually render anything.

Even on a build with logging added to the 3d sorting/handling code it isn't getting any output.

Once stopped the tab does not produce any more  output, even though devtools reports the positon of main thread animations continues to change, and even when the page is reloaded.

I notice in ,gpu traces that swap buffer calls seem to have stopped.


I haven't bisected across versions.
hang-min.html
4.2 KB View Download

Comment 1 by petermayo@chromium.org, Dec 2 2016 

Bisect says

You are probably looking for a change made after 423188 (known good), but no later than 423689 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/88dc583d32e0ec09b9afacb2dfa71ef531b30a80..b440caef76273a30858144990c14bc4fa9793525


Wow, there were a lot of builds in that range that don't run.

Comment 2 by petermayo@chromium.org, Dec 2 2016

Cc: enne@chromium.org
Manual bisect points at this:
commit 8c14bf7d37bec879a5caa162f2c72a303da1a6e0
Date:   Wed Oct 5 12:10:31 2016 -0700

Comment 3 by enne@chromium.org, Dec 2 2016

Cc: danakj@chromium.org vmp...@chromium.org
That's...unfortunate.  That means that this was previously depending on undefined overflow behavior somewhere in the pipeline.  I don't understand why frames aren't continuing to be pumped, though.

Comment 4 by petermayo@chromium.org, Dec 2 2016

Labels: M-55 M-56
Oh bother, this is in earlier releases than I knew
Validated it freezes a pixel 1 on ChromeOS 56

Comment 5 by petermayo@chromium.org, Dec 5 2016 

M55 - stable channel release exhibits this freeze in both the test and and in the wild. (626095)

Comment 6 by ajuma@chromium.org, Dec 9 2016

Cc: ajuma@chromium.org
The compositor is starting impl frames as usual, but draws are earlying out because of no damage. So somewhere in the damage rect computation the clamping of overflow must be causing a previously non-empty rect to become empty.

Comment 7 by weiliangc@chromium.org, Dec 12 2016

Cc: weiliangc@chromium.org

Comment 8 by vmi...@chromium.org, Jan 19 2017

Owner: enne@chromium.org
Status: Assigned (was: Untriaged)
This P1 hang seems to have dropped of the radar?  Assigning to enne@ per #2.

This seems still reproducible as of 57.0.2985.0.

Comment 9 by enne@chromium.org, Jan 19 2017

Mergedinto: 678432
Status: Duplicate (was: Assigned)
If I hack cc::DamageTracker to always have a damage rect of gfx::Rect(0,0,10000,10000) then this runs fine.  I think this is a duplicate of  issue 678432 .
►

Sign in to add a comment