Issue metadata
Sign in to add a comment
|
Performance degrades with canvas compositing operations on high dpi screens
Reported by
te...@chartiq.com,
Mar 15 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Steps to reproduce the problem: 1. On a 4k machine, stack multiple canvases on the DOM. 2. Render graphics on the bottom canvas. 3. What is the expected behavior? Performance should be consistent regardless of the superimposed canvases. What went wrong? Performance degrades with each canvas that is superimposed. Did this work before? Yes 56 Does this work in other browsers? Yes Chrome version: 57.0.2987.98 Channel: stable OS Version: 10.0 Flash Version: Compositing operations even on a single canvas have poor performance but this test case provides a clear, measurable example and demonstrates that this is a generalized compositing issue. This bug does not exhibit on computers without a high dpi screen. This bug also exhibits in some versions of FF but not in IE.
,
Mar 17 2017
Tested this issue on Windows-10 HiDpi using chrome stable #57.0.2987.98 and observed the below M57 value. I have checked the same on different browsers and observed different fps value. Could you please let us know what's the expected fps range to test this issue from Chrome-TE end? ------------------------------------- | Browser | fps | |-----------------------------------| |IE | 23.681592039800993 | |Firefox | 7.672634271099744 | |Chrome M56 | 8.069277701239912 | |Chrome M57 | 6.0772397569104095 | -------------------------------------
,
Mar 17 2017
These results are similar to what we were seeing on a Dell Inspiron 7000. If you reduce the numberOfCanvases to 1 then you should see fps around 11. I would consider that the low bar. If IE is hitting 23 then we know that is possible (aim high!) but I think that is beyond the scope of the compositing issue specifically.
,
Mar 17 2017
Thank you for providing more feedback. Adding requester "brajkumar@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
,
Mar 20 2017
,
Apr 25 2017
Windows 10 HIDPI behavior is updated in Comment#3. As Chrome-Hyd team do not have 4K machine to test this issue adding 'TE-Hardware-Dependency' label to the issue. Thank you..!!
,
Apr 25 2017
,
Apr 25 2017
There are two issues here, one is a antialiasing line drawing problem, that I've split it to b715116. The other is a compositing issue that we will keep here. on comment #2: For the windows-10 HiDpi, could you please run this updated test that does 1,10,100 canvases and outputs the ratio too. On Mac highdpi (2x) what I see is: ---------------------------------------------- | Browser | Ratio | FPS1 | FPS10 | FPS100 | |------------|-------|------|-------|--------| | Chrome M57 | 2 | 24.8 | 24.2 | 18.4 | | Firefox | 2 | 19.0 | 19.2 | 13.9 | | Safari | 2 | 18.3 | 17.8 | 12.3 | ---------------------------------------------- Which seems okey to me, considering those canvas do generate a load on the DOM.
,
Jul 31 2017
fserb@ can we have the latest update on this issue? Updating labels and removing from bisect bucket since TE cannot repro.
,
Aug 1 2017
I've asked for a verification, but didn't get a reply. On Mac, performance seems consistent. I'm getting a Win10 hidpi this week to check it further.
,
Aug 13
Can't repro. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by ajha@chromium.org
, Mar 16 2017