Issue metadata
Sign in to add a comment
|
Bad performance of software 2D canvas rendering with 61
Reported by
jakub.go...@gmail.com,
Oct 11 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.105 Safari/537.36 Vivaldi/1.92.917.43 Example URL: http://orteil.dashnet.org/cookieclicker/ Steps to reproduce the problem: Flag "#disable-accelerated-2d-canvas" is Enabled by default. (as per internal //flags page) 1. Disable "#disable-accelerated-2d-canvas" flag (forces software rendering) 2. Restart, Visit the page 3. Try interacting then compare with: 1. Enable "#disable-accelerated-2d-canvas" flag (default, uses GPU for rendering) 2. Restart, Visit the page 3. Try interacting What is the expected behavior? Page should be responding fast. What went wrong? Page is a slideshow, runs very slowly (ie. few frames per second) Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? Yes 60.0.3112.105 Does this work in other browsers? Yes Chrome version: 61.0.3163.102 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 25.0 r0 This was working fine on 60.0.3112.105, got broken under 61.0.3163.102. When disabling the flag you can see on 60 it runs fine, on 61 it's terrible, clearly indicating some recent changes to Chromium did it. Reproduced on few browsers that use Chromium engine. Seems software rendering in no longer capable of achieving same performance on 61 as it did on 60. However the performance difference is huge, suggesting it's actual defect with software rendering on 61. Few more website are affected that extensively use 2d canvases
,
Oct 12 2017
Unable to reproduce the issue on Win-10 using chrome reported version #61.0.3163.102, latest stable #61.0.3163.100 and latest canary #63.0.3237.7. Attached a screen cast for reference. Following are the steps followed to reproduce the issue. ------------ 1. Disabled "#disable-accelerated-2d-canvas" flag (forces software rendering) 2. Restarted and navigated to page http://orteil.dashnet.org/cookieclicker/ 3. Interacted and observed that page responded fast. Note: Same behavior is observed with chrome version #60.0.3112.105 also Reporter@ - Could you please check the issue on latest canary #63.0.3237.7 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not. Thanks...!!
,
Oct 12 2017
Hi @krajshree ... I can confirm that 63 works fast again. To show the issue, I'm running both (though not exactly same version as you mentioned buy close enough) ... side by side and recorded it. You can guess which one is 63 (63.0.3236.0) and which one 61 (61.0.3163.100), even without performance stats it's clearly visible that 61 performance here is terrible, 63 same as 60 - fast. Both browsers are clean installations. The lag sees to be caused by "Painting" (Composite Layers) Glad it's fixed ... eventually :)
,
Oct 12 2017
Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 13 2017
Unable to reproduce the issue on Win-10 using chrome latest stable #61.0.3163.100. Attached a screen shot for reference. Could anyone from blink team please have a look into the issue. Note: Removing the Needs-Bisect label as it is not reproducible from TE-end. Please feel free to add the same if required. Thanks...!!
,
Oct 13 2017
,
Oct 13 2017
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by ligim...@chromium.org
, Oct 11 2017