Alpha channel halved when calling CanvasRenderingContext2d clearRect(), drawImage(HTMLCanvasElement)
Reported by
jamie.p...@gmail.com,
Mar 3 2016
|
||||||
Issue descriptionChrome Version : 48.0.2564.116 m URLs (if applicable) : http://www.stoneycreekwinepress.com/wine-labels/What's_New/Photo_Heart_-_Large_Vertical http://www.stoneycreekwinepress.com/test/testcase_doublealpha2.html Other browsers tested: Add OK or FAIL, along with the version, after other browsers where you have tested this issue: Safari: page OK, testcase: FAIL Firefox: page OK, testcase: FAIL IE: page OK, testcase: FAIL Chrome: page FAIL, testcase: FAIL What steps will reproduce the problem? 1. create 2 canvases 2. draw text with a shadow on A, then call clearRect() to clear the entire canvas. (Canvas A is actually 100% clear at this point) 3. draw text with shadow on B, then call A.drawImage(B); What is the expected result? Images on both canvases should have the same alpha. Canvas A and B should have identical images. What happens instead? Image on canvas A has approximately 1/2 the value it should for the text shadow's alpha channel. Canvas A and canvas B do NOT match. Please provide any additional information below. Attach a screenshot if possible. Smells like an alpha premultiplication bug? Do all these browsers use SKIA as well? Seems odd that i can reproduce across them, but it's not happening 'in the wild'. A work-around is to use getImageData() and setImageData() instead of drawImage() though i'm betting it's not as fast.
,
Mar 4 2016
Upon review it looks like the specific codepath that causes this behavior in the application does not happen in other browsers. It's purpose is to queue multiple lines of text to draw one at a time at 10ms intervals to prevent locking the user thread. (other browsers don't take as long to draw the text, and don't trigger the degraded performance path) Unfortunately the slow codepath will get slower now (by a very small amount) getImageData()+putImageData() takes ~5ms drawImage() takes 0-1ms
,
Mar 4 2016
A bug has been reported against firefox here: https://bugzilla.mozilla.org/show_bug.cgi?id=1253504
,
Mar 4 2016
jamie.pate@Could you please provide sample test file with actual and expected behavior screencast for better understanding the issue to triage it further.
,
Mar 4 2016
I'm not sure exactly what that would add to the test case and screenshot I have already provided. It has a radio button which you can toggle to simulate actual/expected behavior built in.
,
Mar 9 2016
Thank you for providing more feedback. Assigning to requester "ssamanoori@chromium.org" for another review. For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 29 2016
jamie.pate@Could you please confirm whether we can close this issue as per comment #7?
,
Mar 29 2016
Yes, the issue was that drawImage() uses the shadow properties as designed but I didn't expect it for some reason. 100% not a bug.
,
Mar 30 2016
Thank you for providing more feedback. Adding requester "ssamanoori@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 31 2016
Closing this issue as per comment #9. Please feel free to file a bug for any further issues with chrome in future. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by ashej...@chromium.org
, Mar 3 2016