drawImage sometimes draws less than the targetWidth/Height
Reported by
andr...@cetrez.com,
Nov 7
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36 Steps to reproduce the problem: Open the HTML-file. Wait a second and the three canvases should be painted black. What is the expected behavior? All three canvases should be completely black, as all three canvases are drawn with the target size exactly matching the canvas. What went wrong? The second canvas will incorrectly leave a white line to the right. The only difference between the three canvases is the source width of the drawImage call, with the left-most being smaller and the right-most being larger. The middle one is between those sizes (just for showing that it's a problem with specific sizes and not the source rectangle). Did this work before? N/A Does this work in other browsers? Yes Chrome version: 69.0.3497.100 Channel: stable OS Version: 10.0 Flash Version: The same bug can be triggered vertically too. This does not seem to happen if the source object is a canvas (or at least not with the same specific sizes).
,
Nov 8
Tried testing the issue on chrome reported version# 69.0.3497.100 using Windows-10 with steps mentioned below: 1) Launched chrome reported version, dragged and dropped the file provided in comment# 0 2) Waite for some time, canvas stayed on same white color @Reporter: Please find the attached screencast for your reference and provide your feedback on it. If possible could you please provide any alternate test file/URL that reproduces the issue which help in further triaging it in better way.
,
Nov 8
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 15
I can confirm the reported behavior on Mac Chrome 70.0.3538.102 - there is a white line on the middle canvas only. Behavior is the same with/without Accelerated 2D Canvas enabled. +fserb@ - would you mind taking a look?
,
Dec 5
So, this has to do with the `sWidth` provided in the `context.drawImage` call. The actual source in the demo is 750px wide. Most `sWidth`s do fill the entire canvas, however some of them have transparent pixels at the rightmost column. Sizes where this happens, for a 750px wide source: 365, 369, 381, 383, 403, 413, 421, 427, 439, 447, 493, 497, 603, 605, 629, 635, 673, 685, 687, 725, 730, 738 738 is the problem size that andreas@cetrez.com noticed above. No pattern in the above numbers jumps out to me yet.
,
Dec 5
That is an interesting set of numbers, but yeah I cannot see any obvious connection. Another fun fact, it only happens when rendering with a dWidth between a single specific interval it seems (varies per sWidth). For sWidth 381, the dWidth interval is 97-191 (inclusive) For sWidth 439, the dWidth interval is 56-220 For sWidth 605, the dWidth interval is 153-303 For sWidth 738, the dWidth interval is 93-185 However, these numbers intuitively seem to rather closely follow "sWidth/dWidth ~= 2^x" where x is some arbitrary integer. I.e. it only happens when downsampling by certain power-of-2 integer factor ranges e.g. 2-4, 2-8, 4-8, etc. It wouldn't surprise me if it's just a rounding error/floating-point edge-case somewhere, e.g. something in the downsampling algorithm uses floating-point where maybe it shouldn't or uses floating-point with lower accuracy and some calculation ends up as X.999... rounds down and terminates too early. Just speculating about the cause, but intuitively something along those lines could make sense to me.
,
Jan 17
(5 days ago)
Currently fixed in dev, looks like this CL did it: https://chromium-review.googlesource.com/c/chromium/src/+/1321774 |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by viswa.karala@chromium.org
, Nov 7