Could you mind to share a URL or sample HTML that reproduces the problem?

Thank you for providing more feedback. Adding requester "kojii@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

I can't see difference between Chrome and Firefox. Can you please point out which line is causing the problem?

In Chrome, I have to scratch all the Card. in FireFox when I scratch 75% of the Card the background will be automatically drawn without scratching the rest (Canvas #1)

Thank you.

Please check the screenshot to see why the problem occurs. especially the color Blue There's +1 on each pixel and it's causing the issue because the percentage will always be less than 75% (match). 

Thank you again.

The bug appears to be related to discrepancies between the gpu-accelerated rendering code and the software rendering code. Canvases smaller than 256-by-256 do not get gpu-accelerated, which is why the small canvas doe not have the bug. 

There appears to be an arithmetic precision bug that causes color  values in the 40-50 range to get a +1.  I don't think the bug is with arc clipping or with drawImage, it is more likely a bug with getImageData or with our heuristic that switches canvases from GPU-acceleration to software mode when getImageData is called repeatedly. Still investigating...

In the mean time, you could workaround the issue by adding tolerance to your comparison instead of looking for exact equality.

Thank you for answer 

I'll add tolerance in my comparison to fix the issue. 

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

commit e522754a2ca86a0efa814330c4e3e4f04dadb64a
Author: Justin Novosad <junov@chromium.org>
Date: Tue Aug 01 17:10:37 2017

Add test that verifies the fidelity of drawImage/getImageData

New test verifies that images tagged with no color space or tagged with
an sRGB color space suffer no loss of precision when drawn to
an sRGB canvas (default or explicitly srgb).

BUG= 747684 

Change-Id: I300001c20ce147ce35a3fa64c64f45396d310250
Reviewed-on: https://chromium-review.googlesource.com/596208
Reviewed-by: Mohammad Reza Zakerinasab <zakerinasab@chromium.org>
Commit-Queue: Justin Novosad <junov@chromium.org>
Cr-Commit-Position: refs/heads/master@{#491025}
[add] https://crrev.com/e522754a2ca86a0efa814330c4e3e4f04dadb64a/third_party/WebKit/LayoutTests/fast/canvas/color-space/ImageData-fidelity.html

After more investigation, I can confirm that the problem is related to the arithmetic precision of GPU-accelerated JPEG decoding.  There are no immediate plans to fix this.

Other possible workarounds:
* Use png files instead of JPEG.
* Store backImage as a canvas instead of an <img> (see attached modified version temp.js) to prevent the image from being re-decoded differently.

Deleted: temp.js 4.8 KB

temp.js 4.8 KB View Download