Issue metadata
Sign in to add a comment
|
Canvas in full screen is very slow in Chrome 65
Reported by
kkeat...@gmail.com,
Apr 12 2018
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 Steps to reproduce the problem: See this discussion https://productforums.google.com/forum/?utm_medium=email&utm_source=footer#!msg/webmasters/BpcA4GXQEjI/KXH7WmKzCAAJ copied from above Going from v64 to v65, I see a huge difference in canvas performance at larger resolutions EDIT--- Test site: http://gaimglass.s3-website-us-west-1.amazonaws.com/chrome/chrome_test.html I added a frame rate counter so you can clearly see how slow Chrome 65 is compared to version 64. At about 1080p resolution I only get about 20Fps on my mac. Then at 4k it drops all the way to about 4fps -- this is extremely problematic considering that in Firefox and Chrome 64, I get 60fps all the way up to 1080 and even at 4k, I'm still getting 30fps in both browsers on this wimpy mac. Chrome 65 did something to canvas and its showing up at higher resolutions. Even on my PC desktop with a GTX 1080Ti video card, I get very low FPS in full screen mode. I suspect that Chrome 65 is no longer using hardware acceleration in the same capacity as previous versions. I have confirmed this on OSX, Windows 7 and Windows 10. What is the expected behavior? Much higher frame rate What went wrong? Frame rate is very low Did this work before? N/A Chrome version: 65.0.3325.181 Channel: stable OS Version: OS X 10.12.6 Flash Version:
,
Apr 12 2018
,
Apr 13 2018
Able to reproduce the issue on Windows 10, mac 10.13.3 and Ubuntu 14.04 using chrome reported version #65.0.3325.181 and latest canary #67.0.3394.0. Bisect Information: ===================== Good build: 65.0.3299.0 Bad Build : 65.0.3300.0 Change Log URL: https://chromium.googlesource.com/chromium/src/+log/898a5a6e89457550e62d2612ab45cbf1d6087775..dc8531cb84f4d3334fc520c2c9269935a90d0c30 Skia CL: https://skia.googlesource.com/skia.git/+log/0dec3af001ac..539040cbf9f6 From the above change log unable to find any possible suspect. Hence, marking it as untriaged and requesting someone from dev team to please help us in assigning it to the right owner. Note: Adding stable blocker for M-66 as it seems to be a recent regression. Please feel free to remove the same if not appropriate. Thanks...!!
,
Apr 13 2018
Let's target this for M67.
,
Apr 16 2018
,
Apr 17 2018
,
Apr 20 2018
I re-ran a bisect experiment and came up with a different range: https://chromium.googlesource.com/chromium/src/+log/13c28e10cccd8b47f35adc8faac806d97077b0a6..ed4cf2db865d9389e83d5410172b1b38e9684033 There is a large skia roll in there. I will do a manual per-revision bisect
,
Apr 20 2018
It seems the root of the slowdown is the use of the blur filter on the 2D rendering context. For some reason, the filter is now triggering GPU readbacks. Suspecting: https://skia.googlesource.com/skia.git/+/297d6efe852ebb98a324a71c79df8f7bbdcc3b94%5E%21/#F2
,
Apr 20 2018
,
Apr 24 2018
Confirmed. This is indeed already fixed in ToT. marking as duplicate. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by kkeat...@gmail.com
, Apr 12 2018