New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 881824 link

Starred by 4 users
Status: Duplicate
Merged: issue 872117
Owner:
█ kbr@chromium.org
OOO until 2019-01-24
Closed: Sep 10
Cc:
sunn...@chromium.org
█ kbr@chromium.org
█ junov@chromium.org
lafo...@chromium.org
aaronhk@chromium.org
vmi...@chromium.org
pbomm...@chromium.org
senorblanco@chromium.org
fs...@chromium.org
davidqu@chromium.org
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Severe performance drop in Canvas based application

Reported by boczu...@goodgamestudios.com, Sep 7 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36

Steps to reproduce the problem:
In two applications that our team is developing we noticed severe performance drops after updating to Chrome 69. Due to legal reasons I can't provide a link to any of them (it will be provided to the Chrome team via a private channel). It seems like drawing operations on a Canvas DOM element are a lot slower in Chrome 69.

What is the expected behavior?
Performance is on par with previous versions of Chrome.

What went wrong?
FPS ratio in both our applications is reduced by a large factor (it drops from 60 FPS to 20 FPS when switching from Chrome 68 to Chrome 69). 

Did this work before? Yes 68 and previous

Does this work in other browsers? Yes

Chrome version: 69.0.3497.81  Channel: stable
OS Version: 10.0.16299
Flash Version: 

We narrowed down the revision range that is causing performance problems by using the bisect tool to: https://chromium.googlesource.com/chromium/src/+log/d74ed58a4e15bee655a1b3398a7b1c8046f8d39e..739049871256fb512841d91a0b8142d695c35546

This is the commit that we suspect of introducing the performance drop: https://chromium.googlesource.com/chromium/src/+/79531c77e491dc9536c985d6c4f5dcd8c6bb48b8

Comment 1 by lafo...@chromium.org, Sep 7

Cc: zmo@chromium.org fs...@chromium.org
Labels: -Pri-2 M-69 ReleaseBlock-Stable Pri-1
Owner: junov@chromium.org
Status: Assigned (was: Unconfirmed)
Hey Justin,

It looks like there maybe a pretty significant performance regression in Chrome 69 that could be related to your change.

Would you mind taking a look?  I'll forward the repro details offline, since they were provided by GGS and likely aren't meant to be in the public domain.

Thanks,

Anthony

Comment 2 by gov...@chromium.org, Sep 7

Cc: pbomm...@chromium.org
We're cutting RC today for M69 respin next week, pls take a look at this ASAP. Thank you.

Comment 3 by gov...@chromium.org, Sep 7

Cc: -zmo@chromium.org lafo...@chromium.org junov@chromium.org
Owner: zmo@chromium.org
Seems like  junov@ is no longer working on chrome, fserb@ is OOO.

zmo@, could you ptal ASAP?

Comment 4 by junov@google.com, Sep 7 

In theory that CL was supposed to be pure refactoring and should not have produced any noticeable changes in behavior or performance (at least not intentionally)
I am not set up for working on Chrome anymore, but if someone can capture traces from before vs after the the suspected CL and attach them to this bug, I'd be glad to take a look at them.

Comment 5 by lafo...@chromium.org, Sep 7

Cc: kbr@chromium.org vmi...@chromium.org
Hey Ken/ Victor, any suggestions?

Comment 6 by capn@chromium.org, Sep 7

Cc: senorblanco@chromium.org davidqu@chromium.org aaronhk@chromium.org

Comment 7 by vmi...@chromium.org, Sep 7

Cc: sunn...@chromium.org
We should check how this looks after Sunny's fix for  Issue 880901 .  My understanding is the regression ranges don't overlap, but it may be that they have similar root causes.

Comment 8 by vmi...@chromium.org, Sep 7 

Reporter: Could you please check if the regression can be reproduced on the latest Canary build?

The regression sounds similar to  Issue 880620 , which seems to have recovered on Canary.

Comment 9 by kbr@chromium.org, Sep 7

Owner: sunn...@chromium.org
I'm not able to reproduce this locally with the test case the customer provided offline. On macOS the framerate on Stable and Canary is the same (60 FPS). On Windows with 69.0.3497.81 (Official Build) (64-bit) (cohort: 69_win_81) it gets 60 FPS. On Windows with 71.0.3545.1 (Official Build) canary-dcheck (32-bit) (cohort: ASAN) the test case also gets 60 FPS.

In all cases the test case is reporting:

"Alert: The connection to the server was interrupted. Please try to reconnect."

But the intro screen claims to be rendering at 60 FPS regardless.

about:gpu from Chrome Stable on my Windows workstation attached.

zmo@ is out right now so let me reassign this to Sunny because he has a good fix for other canvas based apps.
about-gpu.txt
14.0 KB View Download

Comment 10 by kbr@chromium.org, Sep 10

Mergedinto: 880901
Status: Duplicate (was: Assigned)
Great news – Sunny's fixes for  Issue 880901  in particular have fixed this regression. Just tested the not-yet-released 69.0.3497.91, and the game is back to full speed (~53 FPS on my late 2013 MacBook Pro with NVIDIA discrete GPU).

Duplicating this into the other issue.

Comment 11 by kbr@chromium.org, Sep 10

Owner: kbr@chromium.org
Status: Assigned (was: Duplicate)
Hmm. I think I duplicated this into the wrong issue; not sure the fix for  Issue 880901  has been merged back to Chrome 69 yet. However, the recent Chrome 69 build does run at full speed. Let me investigate further.

Comment 12 by kbr@chromium.org, Sep 10

Mergedinto: -880901 872117
Status: Duplicate (was: Assigned)
Confirmed that Chrome 69.0.3497.81 is slow and 69.0.3497.91 is fast with the customer's test case. This is a duplicate of  Issue 872117 .

Comment 13 by gov...@chromium.org, Sep 11 

Good news: 69.0.3497.92 is now available with the fix on Chrome Stable. You can force an update by visiting chrome://chrome. Thank you.
►

Sign in to add a comment