1950085 - canvas.drawImage() doesn’t render SVG with clip-path and mix-blend-mode as expected

Status: RESOLVED FIXED

(Core :: Graphics: Canvas2D, defect)

Description

[nrmnrsh]

Attachment: Archive.zip contains a reproducible set up with an SVG and canvas rendering

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36

Steps to reproduce:

Load an SVG image with an <img /> tag. The loaded SVG contains a clip-path that is applied to a group. Inside the group, there is an image element that is rendered with a mix-blend-mode.

• USerAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:135.0) Gecko/20100101 Firefox/135.0
• Browser: Firefox 135.0.1
• Operating System: Mac OS 15.3 (24D60)
• Hardware: Apple M3 Pro

Actual results:

When using this SVG image and rendering it on a canvas with drawImage(), the offset of the clip-path to the right and bottom is displayed as a stretched image.

Expected results:

The result of drawImage() should render the image on the canvas exactly as the original image.

Comment 1

[nrmnrsh]

Attachment: Screenshot of the rendering

The screenshot shows the actual rendering issue in Firefox. At the top, there is an <img> element that loads the SVG. This image is then used to call drawImage() on the <canvas> element, which is rendered at the bottom.

Comment 2

[Alice0775 White]

I can reproduce on Nightly137.0a1 Windows11.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=affc4eac7db07097c3b16a9059a64e2cc1710d40&tochange=fe10049200dfa92f958f65b9fc37fef345694b41

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1910138

:lsalzman, since you are the author of the regressor, bug 1910138, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 4

[Lee Salzman [:lsalzman]]

Timothy, this seems like a bug in SVG rendering.

Comment 5

[Lee Salzman [:lsalzman]]

Attachment: Bug 1950085 - Handle offset surfaces in DrawTargetWebgl::DrawSurface. r?aosmond

Comment 6

[nrmnrsh]

I need to clarify my description of the bug. After further testing, I’ve realized that it is not related to clip-path. Instead, it is specifically caused by mix-blend-mode applied to a group. As a result, the actual positions of the objects inside the group are lost, causing them to shift to the coordinate origin (top/left = 0,0). This leads to an offset on the bottom/right, appearing as a glitch/distortion. I will add an other example...

Comment 7

[nrmnrsh]

Attachment: Archive 2.zip

A new example with mix-blend-mode only.

Comment 8

[nrmnrsh]

Attachment: mix-blend-mode-only.png

The left side shows the SVG loaded into an <img>, while the right side displays the SVG rendered on a <canvas> using canvasContext2d.drawImage().

Comment 9

[Ryan VanderMeulen [:RyanVM]]

This has presumably affected Linux and Mac since bug 1806058.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/555f78811ae0
Handle offset surfaces in DrawTargetWebgl::DrawSurface. r=aosmond

Comment 11

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/555f78811ae0

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:lsalzman, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox136 to wontfix.

For more information, please visit BugBot documentation.

Comment 13

[nrmnrsh]

Attachment: nightly build 137.0a1 (2025-02-26).png

Comment 14

[nrmnrsh]

:smolnar, I've tested the nightly build 137.0a1 (2025-02-26) with my attached file Archive2.zip. The positioning works fine, but there is still a glitch with on the border of the shape... see screenshot

Comment 15

[Lee Salzman [:lsalzman]]

Attachment: Bug 1950085 - Ensure DrawTargetWebgl::DrawSurface clips drawing to surface bounds. r?aosmond

For offset surfaces, the source rect to DrawSurface may not actually be entirely filled by
the surface's contents. In this case, we need to clip the source and dest rects to reflect
the actual surface content bounds.

This required some collateral modifications to make using offset surfaces safe in a few other
places in DrawTargets in general.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5587ed6a3e35
Ensure DrawTargetWebgl::DrawSurface clips drawing to surface bounds. r=aosmond

Comment 17

[amarc]

https://hg.mozilla.org/mozilla-central/rev/5587ed6a3e35