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

Issue 640144 link

Starred by 2 users
Status: Fixed
Owner:
█ junov@chromium.org
Last visit > 30 days ago
Closed: Oct 2016
Cc:
hirosh...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug-Regression



Sign in to add a comment

canvas-to-canvas drawImage() became slower after r406950:r406959 when getContext()/getImageData() are called

Project Member Reported by hirosh...@chromium.org, Aug 23 2016 
Version: r406959 (54.0.2804.0)
OS: Windows 7 (does not occur on Linux)

The performance of canvas-to-canvas drawImage() in the case where
1. getContext('2d') is called for the source canvas, and
2. getImageData() is called for the target canvas
was regressed in r406950:r406959.

    var context = canvas.getContext('2d');
    context3 = img.getContext('2d'); // 1.
    imageData = context.getImageData(200, 201, 1, 1); // 2.
    context.drawImage(img, 20, 20);

What steps will reproduce the problem?
(1) Open the attached HTML. (which executes drawImage() 100 times under the conditions above)

What is the expected output?

On Chrome 52.0.2743.116 (Official Build) m on Windows 7: ~1 msec
On Firefox 48.0 on Windows 7: ~1 msec

What do you see instead?

54.0.2829.0 (Official Build) canary on Windows 7: 200~300 msec

Please use labels and text to provide additional information.

./tools/bisect-builds.py result:
- r406949 is good
- r406959 is bad

List of CLs:
https://chromium.googlesource.com/chromium/src/+log/068ace2593da95f2f47b20432e02e8d1e3706807..0e57a1efd2a6f47e492c7d990eb397dfab5402a0

Suspected CL:
https://codereview.chromium.org/2171513003

On Linux, the performance didn't change:
- 54.0.2816.0 (Official Build) beta (64-bit): ~6 msec
- 52.0.2743.116 (Official Build) (64-bit): ~6 msec

I'm not sure whether this impacts on applications in the wild, but reporting here anyway.
(As one datapoint, my personal web application regressed due to this)
anri-min.html
665 bytes View Download

Comment 1 by hirosh...@chromium.org, Aug 23 2016 

FYI
The following is performance data with/without getContext()/getImageData().
(Open attached HTML to execute the test)

On Google Chrome	52.0.2743.116 (Official Build) m (64-bit)
Calling getContext() for the source canvas makes drawImage() faster.
toGetImgContext=false, toGetImageData=false, ~150 msec
toGetImgContext=false, toGetImageData=true, ~100 msec
toGetImgContext=true, toGetImageData=false, ~1 msec
toGetImgContext=true, toGetImageData=true, ~1 msec

On Google Chrome	54.0.2829.0 (Official Build) canary (64-bit)
toGetImgContext=false, toGetImageData=false, ~200 msec // Slower?
toGetImgContext=false, toGetImageData=true, ~50 msec // Faster
toGetImgContext=true, toGetImageData=false, ~1 msec // Unchanged
toGetImgContext=true, toGetImageData=true, ~300 msec // Slower
anri.html
1.3 KB View Download

Comment 2 by junov@chromium.org, Aug 23 2016 

It is by design that calling getImageData disables GPU acceleration (because GPU readbacks are expensive), but I think we should make a cleverer heuristic to minimize special case regressions.

Comment 3 by hirosh...@chromium.org, Aug 23 2016 

Thanks for feedback.
I looked at tracing and found a GLES2::ReadPixels and sync IPC block per one drawImage() call.
Does this mean GPU acceleration is still enabled and causing expensive readbacks?
trace.png
50.8 KB View Download

Comment 4 by junov@chromium.org, Aug 23 2016 

That mean you are drawing from a GPU-accelerated source to a non-GPU-accelerated destination
Project Member

Comment 5 by bugdroid1@chromium.org, Oct 4 2016 

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

commit 2b0d65c9311d7e87784e90d60bfc68efb5f03555
Author: junov <junov@chromium.org>
Date: Tue Oct 04 17:36:28 2016

Disable GPU acceleration on 2D canvas when readbacks are needed

We are already disabling GPU acceleration to avoid readbacks caused
by calls to getImageData. This change applies the same principle
to canvas-to-canvas drawImage calls in order to avoid probable
future readbacks.

BUG= 652126 ,  651517 ,  650116 ,  642539 ,  640144 

Review-Url: https://codereview.chromium.org/2388293002
Cr-Commit-Position: refs/heads/master@{#422848}

[modify] https://crrev.com/2b0d65c9311d7e87784e90d60bfc68efb5f03555/third_party/WebKit/Source/core/html/HTMLCanvasElement.cpp
[modify] https://crrev.com/2b0d65c9311d7e87784e90d60bfc68efb5f03555/third_party/WebKit/Source/modules/canvas2d/CanvasRenderingContext2DTest.cpp
[modify] https://crrev.com/2b0d65c9311d7e87784e90d60bfc68efb5f03555/third_party/WebKit/Source/platform/graphics/ExpensiveCanvasHeuristicParameters.h

Comment 6 by junov@chromium.org, Oct 4 2016

Status: Fixed (was: Assigned)
►

Sign in to add a comment