New issue
Advanced search Search tips

Issue 769282 link

Starred by 5 users

Issue metadata

Status: Available
Owner: ----
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug-Regression

Blocked on:
issue 706456



Sign in to add a comment

polygraph.cool/hamilton/ causes regressed to <1fps due to GpuRasterBuffer::Playback

Reported by samcc...@gmail.com, Sep 27 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36

Steps to reproduce the problem:
1. visit  https://pudding.cool/2017/03/hamilton/index.html
2. scroll on the page

What is the expected behavior?
The scrolling is smooth and the animation is smooth and the page content does not checkerboard 

What went wrong?
The page is super slow, and no longer reacts to scroll events and does not paint.

perf audit thread
https://twitter.com/samccone/status/913029540229844992

Did this work before? Yes 4 weeks ago (according to the author)

Chrome version: 61.0.3163.100  Channel: stable
OS Version: OS X 10.12.5
Flash Version:
 
Description: Show this description
Cc: junov@chromium.org
Components: -UI Internals>Compositing Blink>Compositing
If I change the first Canvas's height to 13817, it hits 60fps. 13818 and performance falls off the cliff.
Summary: polygraph.cool/hamilton/ causes regressed to <1fps due to GpuRasterBuffer::Playback (was: polygraph.cool/hamilton/ causes the Compositor/Renderer to slow to a crawl)

A trace points to heavy cost in GpuRasterBuffer::Playback.

Seems connected to the other m61 canvas perf issues floating around.


Components: Blink>Canvas

Comment 7 by woxxom@gmail.com, Sep 27 2017

FWIW I see minor jank on scrolling in Windows7 too, here's a per-snapshot bisect:
https://chromium.googlesource.com/chromium/src/+log/d2021c96..14232dcc?pretty=fuller
The only Canvas-related CL is r471808 "Disable 2D canvas deferral on text rendering when compositing"

Components: -Blink>Compositing -Internals>Compositing
Leaving for canvas triage as that group may know the source of the magic 13818 cliff.

Comment 9 by junov@chromium.org, Sep 27 2017

Status: Available (was: Unconfirmed)
The magic cliff has to do with the maximum amount of GPU memory that we allow to be used for accelerating canvases.  We don't yet have centralized GPU resource management so there's currently a hard-coded limit. When that limit is exceeded, we fall back to software rendering mode.

In general canvas is not well suited for making drawing areas that are much larger than the screen: it results in very large buffers being allocated, which may result in OOM crashes, and general slowness.  The soon to be shipped CSS Paint API would be a much better solution, or SVG.

A sliding canvas that follows scroll position would also be a tempting solution
Blockedon: 706456
Cc: -junov@chromium.org

Sign in to add a comment