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

Chrome 69 is slower rendering with hardware acceleration on

Reported by dat...@gmail.com, Sep 5

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.81 Safari/537.36

Steps to reproduce the problem:
1. Turn Hardware Acceleration Off in Google Chrome
2. Go to https://dev3.orgchartnow.com
3. login using the following creds: google@google.com
4. Password: tbs2rt
5. A chart will open
6. Click on the gear icon while holding down the shift key
7. Select 'Test Performance'
8. Repeat a number of times.
9. Turn Hardware Acceleration On in Google Chrome
10. Repeat steps 2-8.

With Hardware Acceleration OFF performance is about 14 FPS. With Hardware Acceleration OFF performance is about 20 FPS. A 40% difference!

What is the expected behavior?
Hardware acceleration performance should be the same or faster.

What went wrong?
Chrome 69 has a performance issue with Hardware Acceleration.

Did this work before? Yes Chrome 67

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

https://bugs.chromium.org/p/chromium/issues/detail?id=872117 might be related. Wasn't an issue in Chrome 67.
 
Similar behavior found in Version 71.0.3543.0 (Official Build) canary (64-bit). Might be about 10% faster (vs 69.0.3497.81) with hardware acceleration on.
Comment #1 should read - With Hardware Acceleration ON performance is about 14 FPS. With Hardware Acceleration OFF performance is about 20 FPS. A 40% difference!

Bisect info: 572133 (good) - 572135 (bad)
https://chromium.googlesource.com/chromium/src/+log/aec6172c..65c38f54?pretty=fuller
Suspecting r572135 = 65c38f54b0ae666e8b27bfa5aef6d3ab92d4a783 = https://crrev.com/c/1105505 by jdarpinian@chromium.org
"GPU: Grow and shrink transfer buffer"
Landed in 69.0.3481.0


gpu.txt
9.3 KB View Download
Cc: jdarpinian@chromium.org
Components: -Blink Internals>GPU
Owner: piman@chromium.org
Status: Assigned (was: Unconfirmed)
Since this has a per revision bisect and jdarphinian@ is OOO assinging to piman@ who reviewed the CL.
Cc: sunn...@chromium.org
Components: -Internals>GPU Internals>GPU>Internals
Owner: vmi...@chromium.org
Thanks for the bisect!
That CL may have winners and losers, but having a repro case as you provided is useful, and we should see if there's something that we can do.

-> vmiura to find an owner
Cc: fs...@chromium.org
Attaching trace. It looks like skia is issuing a very large number of commands, and we end up filling up the command buffer, and blocking on execution on the GPU side, losing overlap. Probably what was happening before James's patch is that we would flush earlier because filling up the transfer buffer, but the autosizing removed the need for that.

We can probably tune the command buffer logic to flush sooner, and/or have SkiaPaintCanvas::FlushAfterDrawIfNeeded explicitly do so.
trace_orgchartnow.json.gz
2.4 MB Download
Hi when can we expect to get a fix for this? I am experiencing the same issue exactly.
i am experiencing the same issue on a lot html5 game, please hot fix this issue.
Hi Pros, is there any update on chrome v69 hardware acceleration issue? It's affecting html5 animation as well. We have tested there were no issue in v70 & v71. Appreciate if you can release a hotfix for v69. We can't wait for v70 or v71. Or provide a solution how can we fix in our code? Thank you.
Cc: pbomm...@chromium.org
Labels: ReleaseBlock-Stable M-69 Target-69
Adding "RBS" for tracking, pls remove if needed. Thank you.
Labels: Target-70 Target-71 M-71 M-70
Worst Release Ever 
why this release version have huge amount of issues occurred especially html5 games, so disappointing. 
Labels: -Pri-2 hasbisect Pri-1
While investigating  Issue 880620  tested the URL updated in C#0 as well.

Below are the observations as tested on Windows-10:
===================================================
68.0.3440.106 -- ~30 FPS
69.0.3480.0 -- ~29 FPS
69.0.3481.0 --~29 FPS
69.0.3487.0 -- ~30 FPS
69.0.3489.0 -- ~29 FPS
69.0.3491.0 -- ~24 FPS<----
69.0.3497.81 -- ~24 FPS
71.0.3545.0 -- ~24 FPS

and Below is tool bisect result:

https://chromium.googlesource.com/chromium/src/+log/581b375d9bb0a4c0bd57ae14b1ed49c7976399b7..6a1536afade0b4d51f5665aa7025370331bb0c15 , which also contains 'GPU: Grow and shrink transfer buffer' by jdarpinian@ as updated in C#3.

As per the test this is still an issue on M-71 canary(71.0.3545.2) and also observed by datnow@ in C#1, however C#9 suggests otherwise. 

azurite2018@: Could you please recheck and confirm whether the issue is resolved from your end on M-70 and M-71 and please provide the html5 animation example you are checking. 
Dear Chromium Team,

Thank you for taking prompt action on this and I appreciate that. I have just retested on 70 and 71 versions and I have to agree with you that the issue exists in both versions too. I hope you can take action immediately to provide fixes on this. I am sorry that I cannot provide html samples due to company policies.

Thank you.
Cc: -sunn...@chromium.org kbr@chromium.org zmo@chromium.org vmi...@chromium.org
Owner: sunn...@chromium.org
sunny, could you please debug this today?
Automatic flushes are supposed to fix this, but it looks like they're
disabled for the shared main thread context (ContextType
RENDERER_MAIN_THREAD seen in trace) that's used by canvas:
RenderThreadImpl::SharedMainThreadContextProvider() calls
RenderThreadImpl::CreateOffscreenContext() which always sets
automatic_flushes to false. I'm going to experiment with enabling automatic
flushes for the canvas context to see if that fixes the problem.

https://cs.chromium.org/chromium/src/content/renderer/render_thread_impl.cc?l=1415&gs=kythe%253A%252F%252Fchromium%253Flang%253Dc%25252B%25252B%253Fpath%253Dsrc%252Fcontent%252Frenderer%252Frender_thread_impl.cc%25236dD2w1QnVtu%25252BT4wDmrItjjlO3BmPkTuUhR4dUtDFk88%25253D&gsn=SharedMainThreadContextProvider&ct=xref_usages
Result of quick test on my corp workstation (2560 x 1440 resolution):
With automatic flush: ~21 fps
Without automatic flush: ~15 fps
Project Member

Comment 20 by bugdroid1@chromium.org, Sep 7

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f3fd321621a946f69068fa5d50dc0c9c505a6bab

commit f3fd321621a946f69068fa5d50dc0c9c505a6bab
Author: Sunny Sachanandani <sunnyps@chromium.org>
Date: Fri Sep 07 22:26:05 2018

Enable automatic flush for canvas context

Automatically growing transfer buffer removed the flush when it would
run of space.  This decreased canvas throughput by reducing pipelining.

Automatic flushes are another way of improving throughput by submitting
work to the GPU process often.  This CL enables automatic flushes for
the shared main thread context used for canvas which might have been
disabled unintentionally.

Bug:  880901 
Change-Id: Ib48d9c56c18c9e2d449d7c42f74b16609ad3ea55
Reviewed-on: https://chromium-review.googlesource.com/1213665
Reviewed-by: Antoine Labour <piman@chromium.org>
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
Cr-Commit-Position: refs/heads/master@{#589688}
[modify] https://crrev.com/f3fd321621a946f69068fa5d50dc0c9c505a6bab/content/renderer/render_thread_impl.cc

Project Member

Comment 21 by bugdroid1@chromium.org, Sep 7

Labels: merge-merged-3545
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/00b22b97594d1321dea803ca8046653731f8aab6

commit 00b22b97594d1321dea803ca8046653731f8aab6
Author: Sunny Sachanandani <sunnyps@chromium.org>
Date: Fri Sep 07 22:32:30 2018

[merge to 3545 canary] Enable automatic flush for canvas context

Automatically growing transfer buffer removed the flush when it would
run of space.  This decreased canvas throughput by reducing pipelining.

Automatic flushes are another way of improving throughput by submitting
work to the GPU process often.  This CL enables automatic flushes for
the shared main thread context used for canvas which might have been
disabled unintentionally.

Bug:  880901 
Change-Id: Ib48d9c56c18c9e2d449d7c42f74b16609ad3ea55
Reviewed-on: https://chromium-review.googlesource.com/1213665
Reviewed-by: Antoine Labour <piman@chromium.org>
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#589688}(cherry picked from commit f3fd321621a946f69068fa5d50dc0c9c505a6bab)
Reviewed-on: https://chromium-review.googlesource.com/1214078
Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
Cr-Commit-Position: refs/branch-heads/3545@{#9}
Cr-Branched-From: a2bbe9dedf867fccce6d8073dc8e9c864c662bfe-refs/heads/master@{#589377}
[modify] https://crrev.com/00b22b97594d1321dea803ca8046653731f8aab6/content/renderer/render_thread_impl.cc

Labels: Merge-Request-69 Merge-Request-70
Cc: gov...@chromium.org
Requested a merge to 69.  There is a little bit of performance risk with this fix, but this is least risky fix in terms of stability.
Project Member

Comment 24 by sheriffbot@chromium.org, Sep 8

Labels: -Merge-Request-69 Merge-Review-69 Hotlist-Merge-Review
This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
NextAction: 2018-09-10
Pls update bug with canary result on Monday morning.
Canary #71.0.3546.0 currently building includes change listed at #20.

Comment 27 Deleted

Project Member

Comment 28 by sheriffbot@chromium.org, Sep 9

Labels: -Merge-Request-70 Hotlist-Merge-Approved Merge-Approved-70
Your change meets the bar and is auto-approved for M70. Please go ahead and merge the CL to branch 3538 manually. Please contact milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
To add to the test results as updated in C#14 this showed ~24 FPS on 71.0.3545.0(build without fix) and is now showing ~28 FPS on the latest canary 71.0.3548.0(build with fix). Latest canary FPS is somewhat closer to the good build behavior as per the testing performed on Windows-10.   
The NextAction date has arrived: 2018-09-10
Cc: jmukthavaram@chromium.org
 Issue 871917  has been merged into this issue.
Cc: junov@chromium.org lafo...@chromium.org senorblanco@chromium.org aaronhk@chromium.org sunn...@chromium.org davidqu@chromium.org
 Issue 881824  has been merged into this issue.
Change at #21 has been out on Canary since Saturday.  It looks good to merge to M69.
Labels: -Merge-Review-69 Merge-Approved-69
Approving merge to M69 branch 3497 based on comment #33. Please merge ASAP. Thank you.
Status: Fixed (was: Assigned)
Merged to M69: 2392f539d8a21692d036287fdaa99275aba00aed

Project Member

Comment 36 by bugdroid1@chromium.org, Sep 10

Labels: -merge-approved-69 merge-merged-3497
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2392f539d8a21692d036287fdaa99275aba00aed

commit 2392f539d8a21692d036287fdaa99275aba00aed
Author: Sunny Sachanandani <sunnyps@chromium.org>
Date: Mon Sep 10 18:20:44 2018

[merge to M69] Enable automatic flush for canvas context

Automatically growing transfer buffer removed the flush when it would
run of space.  This decreased canvas throughput by reducing pipelining.

Automatic flushes are another way of improving throughput by submitting
work to the GPU process often.  This CL enables automatic flushes for
the shared main thread context used for canvas which might have been
disabled unintentionally.

TBR=piman@chromium.org

(cherry picked from commit f3fd321621a946f69068fa5d50dc0c9c505a6bab)

Bug:  880901 
Change-Id: Ib48d9c56c18c9e2d449d7c42f74b16609ad3ea55
Reviewed-on: https://chromium-review.googlesource.com/1213665
Reviewed-by: Antoine Labour <piman@chromium.org>
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#589688}
Reviewed-on: https://chromium-review.googlesource.com/1216073
Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
Cr-Commit-Position: refs/branch-heads/3497@{#918}
Cr-Branched-From: 271eaf50594eb818c9295dc78d364aea18c82ea8-refs/heads/master@{#576753}
[modify] https://crrev.com/2392f539d8a21692d036287fdaa99275aba00aed/content/renderer/render_thread_impl.cc

Note: Had to merge to manually because of ui->ws namespace changes. Verified that it compiles.
Project Member

Comment 38 by bugdroid1@chromium.org, Sep 10

Labels: -merge-approved-70 merge-merged-3538
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4459bfd9798c0c8175d57e0e8b9dc3d6e945e2dc

commit 4459bfd9798c0c8175d57e0e8b9dc3d6e945e2dc
Author: Sunny Sachanandani <sunnyps@chromium.org>
Date: Mon Sep 10 18:24:55 2018

[merge to M70] Enable automatic flush for canvas context

Automatically growing transfer buffer removed the flush when it would
run of space.  This decreased canvas throughput by reducing pipelining.

Automatic flushes are another way of improving throughput by submitting
work to the GPU process often.  This CL enables automatic flushes for
the shared main thread context used for canvas which might have been
disabled unintentionally.

Bug:  880901 
Change-Id: Ib48d9c56c18c9e2d449d7c42f74b16609ad3ea55
Reviewed-on: https://chromium-review.googlesource.com/1213665
Reviewed-by: Antoine Labour <piman@chromium.org>
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#589688}(cherry picked from commit f3fd321621a946f69068fa5d50dc0c9c505a6bab)
Reviewed-on: https://chromium-review.googlesource.com/1217170
Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#235}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
[modify] https://crrev.com/4459bfd9798c0c8175d57e0e8b9dc3d6e945e2dc/content/renderer/render_thread_impl.cc

Tested with Version 71.0.3548.0 (Official Build) canary (64-bit)
17.25 FPS with HW Accel On
21.5 FPS with HW Accel Off

Better... but you would think HW Accel would win.
#39: it depends on your canvas usage.  There are many cases in which GPU Canvas rendering is faster, but the rendering you're doing may not necessarily be efficient on the GPU.  Did it use to be faster in other Chrome versions?
Labels: TE-Verified-M69 TE-Verified-69.0.3497.92
Tested this on Win-10 using version 69.0.3497.92 and FPS count seems to have improved as compared to 69.0.3497.81(24 FPS, updated in C#14). Seeing 27-29 FPS for the repro case in C#0 on 69.0.3497.92. Hence adding the verified label.
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.
Labels: TE-Verified-M70 TE-Verified-70.0.3538.16
Adding the verified label for 70.0.3538.16 as well. Tested on Windows-10 and FPS is ~27-29.
Requesting a postmortem for this, pls see go/chrome-postmortems for more details.

Sign in to add a comment