Bug 159340 – Drawing an <img> with an SVG source into a <canvas> has incorrect rendering if the SVG viewBox does not match the <img> metrics

• Component: SVG
• Status: NEW

[Antoine Quint]

Created attachment 282532 [details]
Testcase

See the attached testcase. In it we have an SVG image which has viewBox="0 0 200 200" and a <circle> with its top left corner located at 40,40 and sized to be 120x120. That SVG image is set as the src of an <img> element which is sized to be 100x100 by calling new Image(100, 100). Then we draw the <img> into a <canvas> sized to be 200x200 with a call to drawImage(image, 20, 20, 60, 60, 0, 0, width, height). Since the SVG image is scaled to be 0.5x its intrinsic size, drawing from a source of 20,20 and 60x60 should be a perfect match for the circle metrics but the output doesn't match, except very rarely when the image draws correctly.

Chrome behaves the same as us and Firefox draws black only.

There was a recent source change to improve this with https://bugs.webkit.org/show_bug.cgi?id=159276, but it seems it doesn't quite cover all cases.

[Radar WebKit Bug Importer]

<rdar://problem/27127786>

[Antoine Quint]

Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=625096.

[Antoine Quint]

Interestingly, this always works with WK1.

[Antoine Quint]

The size of the container for the SVGImage is coming from this line in CanvasRenderingContext2D::drawImage(HTMLImageElement&, const FloatRect&, const FloatRect&, const CompositeOperator&, const BlendMode&, ExceptionCode&):

    FloatRect imageRect = FloatRect(FloatPoint(), size(imageElement, ImageSizeBeforeDevicePixelRatio));

In the WK1 case, when SVGImageCache::imageSizeForRenderer() is eventually called, it finds an `image` which has clearly already been laid out and has a 100x100 size, which is used to size the container.

In the WK2 case, SVGImageCache::imageSizeForRenderer() does not find an image and returns the intrinsic size instead, which is 200x200.

[Antoine Quint]

If the <img> element is not added to the DOM, the failure also occurs on WK1.

[Antoine Quint]

The Chromium bug is a WONTFIX as the behaviour is as spec'd, see discussion in https://bugs.chromium.org/p/chromium/issues/detail?id=625096. It looks like on WK2 we're doing the right thing, while on WK1 we're not, and not the other way around as previously thought.

Basically, when drawing an <img> which points to an SVG image in a <canvas>, the size of the <img> is irrelevant. If the <svg> element specifies width/height attributes, then those should be used as the source image size, otherwise the size should be computed based on the SVG image's aspect ratio based on the viewBox attribute and the size of the <canvas> image.

I'll do a pass through our tests to check that we're correctly implementing this.

[Said Abou-Hallawa]

Created attachment 283040 [details]
Testcase with setTimeout

The rendering can be different in WK2 when calling drawImage() from setTimeout().

[Ahmad Saleem]

All three browsers differ in the "test case" and "test case with setTimeout":

** Safari Technology Preview 154 ***

In second 200 * 200, it shows "full green" circle. Same for other test in both squares / boxes.

*** Chrome Canary 108 ***

In second 200 * 200, it shows "1/4 green" circle (kind of arc). Same for other test in both squares / boxes.

*** Firefox Nightly 107 ***

In second 200 * 200, it shows "complete black" with no green circle. Same for other test in both squares / boxes.

______

Just wanted to share updated testing results. Thanks!