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

Issue 775549 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows , Mac
Pri: 3
Type: Bug



Sign in to add a comment

CanvasRendingContext2D#getImageData slow when iterating by a single pixel.

Reported by co...@chartiq.com, Oct 17 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36

Steps to reproduce the problem:
1. Create canvas at least 740x460 px.
2. Add any specific color in the lower right.
3. Scan by one pixel at a time `getImageData(x, y, 1, 1)` until you find the given color.

What is the expected behavior?

What went wrong?
The request can take several seconds. In some cases the specific color is never returned.

Did this work before? N/A 

Chrome version: 61.0.3163.100  Channel: stable
OS Version: OS X 10.12.6
Flash Version: 

Here is the sample code https://gist.github.com/448654b1cf01ce873f44d9bbe1d7c306

Note that on Firefox this same code performed reasonably (about 500-1200 milliseconds).
 
Labels: Needs-Triage-M61
Cc: divya.pa...@techmahindra.com
Components: Blink>Canvas
Labels: Needs-Feedback Triaged-ET
@codyt: Could you please provide sample file with the above test case for ease of reproduction, that would help us in triaging the issue from TE-end
Components: -Blink

Comment 4 by co...@chartiq.com, Oct 18 2017

Sure! This template is taking over 121,000 milliseconds on my machine.

https://gist.github.com/46cf1366f54dd45bac44272822cffcc1
contains-color.js
509 bytes View Download
index.html
434 bytes View Download
index.js
767 bytes View Download
Project Member

Comment 5 by sheriffbot@chromium.org, Oct 18 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "divya.padigela@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 6 by co...@chartiq.com, Oct 18 2017

The same template executed in 839 milliseconds on FireFox (56.0, 64-bit on Ubuntu).
Cc: pnangunoori@chromium.org
Labels: Needs-Feedback
Tested on latest Chrome Stable #62.0.3202.62 & Canary #64.0.3247.0 on Windows 10, Mac 10.12.6 and Ubuntu 14.04 based on the test case provided in the C# 4 and observations are as below:

Observations:
1. Results on Mac 10.12.6 are
Chrome #64.0.3247.0 - 124482.6400 ms
Chrome #62.0.3202.62 - 128078.9300 ms
Chrome #50.0.2624.0 - 113433.0050 ms

2. Results on Windows 10 are 
Chrome #64.0.3247.0 - 80540.4600 ms
Chrome #62.0.3202.62 - 79251.5800 ms
Chrome #50.0.2624.0 - 66084.2950 ms

3. On Ubuntu 14.04 even after waiting for more than 10 minutes, results are not displayed.

Attached the screenshots for reference.

@codyt -- Thanks for providing the test case. Could you please look into the observations and let us know the expected values.

Thanks.

775549-Mac.png
155 KB View Download
775549-Windows.png
129 KB View Download
775549-Linux.png
51.6 KB View Download

Comment 8 by co...@chartiq.com, Oct 25 2017

Unsure what the expectation should be, but anything under Chrome's "page is unresponsive" timer would probably be good enough. Otherwise under 2000 ms per megabyte of data.
Project Member

Comment 9 by sheriffbot@chromium.org, Oct 25 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "pnangunoori@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
Cc: hdodda@chromium.org
Labels: M-64 OS-Windows
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on windows 10 , Mac os 10.12.6 using chrome M62 #62.0.3202.62 and canary M64 #64.0.3250.0 .

Issue is seen from M50 and is a Non-Regression issue.

Marking it as untraiged for further inputs on this.

Thanks!

Comment 11 by junov@chromium.org, Oct 30 2017

Labels: -Pri-2 Pri-3
Status: Available (was: Untriaged)
An obvious workaround you could use in production right away is to call getImageData once to fetch the entire area of interest in a single large ImageData object, and scan over that.  That should boost performance not just in Chrome, but in all browsers

The problem in Chrome is that every single call to getImageData is generating a readback from the GPU, which is a slow operation.  We have a performance heuristic that switches canvases to software rendering mode (no GPU) when getImageData is use a lot. The problem is that the heuristic looks for cases where getImageData is used in three consecutive animation frames.  We need to change that rule so that it will catch cases like this.

Project Member

Comment 12 by sheriffbot@chromium.org, Oct 31

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Cc: fs...@chromium.org
Status: Available (was: Untriaged)

Sign in to add a comment