1702266 - large svg as css background image is blurry

Status: UNCONFIRMED

(Core :: Graphics: ImageLib, defect)

Description

[jedierikb]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 11_2_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36

Steps to reproduce:

Create an svg with a large width and height.
Append a polygon to the svg.
Render the svg as a background-image to a div.

Try this svg and test it here https://yoksel.github.io/url-encoder/

<svg xmlns="http://www.w3.org/2000/svg" width="137000" height="137000">
<polygon points="60,60 0,60 0,0 60,0" style="fill:lime;stroke:purple;stroke-width:1"/>
</svg>

Actual results:

The svg polygon becomes blurry.

Expected results:

The svg polygon should not be blurry.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::SVG' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Here's a standalone / self-contained version of the reporter's testcase.

The background-image here is:

data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='137000' height='137000'%3E%3Cpolygon points='60,60 0,60 0,0 60,0' style='fill:lime;stroke:purple;stroke-width:1'/%3E%3C/svg%3E

EXPECTED RESULTS: The attached HTML should look crisp (as crisp as that^ SVG looks).
ACTUAL RESULTS: The attached HTML has very blurry edges around the lime area.

Comment 3

[Daniel Holbert [:dholbert]]

Note that this is creating a 137000px by 137000px image, and then clipping off the upper-left 100px-by-100px region. (Strictly speaking, we could just draw the upper left 100px by 100px area and ignore the rest, but I'm not sure our APIs or image drawing logic can figure that out.)

I suspect that in our image code, this scenario is triggering some sort of fallback where we refuse to actually rasterize to a surface that big, and we downscale to our maximum-allowable-surface-size instead, or something to that effect. And then we have to upscale the downscaled image in order to draw that upper-left corner at full resolution as the div background, and this causes some blurriness.

Comment 4

[Daniel Holbert [:dholbert]]

(I would bet the same thing would happen for a 137000px by 137000px PNG image, too, but I haven't tested that.)

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #4)

(I would bet the same thing would happen for a 137000px by 137000px PNG image, too, but I haven't tested that.)

(On a whim, I tried to create a 137000 x 137000 PNG image in Gimp to test this theory, but Gimp warned me: You are trying to create an image with a size of 174.9 GB. An image of the chosen size will use more memory than what is configured as "Maximum new image size". That's definitely more memory than I have, so I can't test that scenario directly, it seems. :) )

Comment 6

[Timothy Nikkel (:tnikkel)]

I believe we will also reject a png over 32000 in one dimension. And we will refuse to create a surface that doesn't fit in the surface cache, which maxes out at 2 GB.

Comment 7

[jedierikb]

Firefox can render scalable vector graphics (svg) with large dimensions, so it would seem a good idea to extend this rendering functionality to the css background-image.

This way designers can more clearly express themselves using your engines.

Instead, our designers resorted to a workaround by inserting the large svg as the child of a positioned container to simulate a background-image.

Firefox is excellent at rendering SVG with large dimensions in this way. It would be nice to extend this functionality to css background-image.

Comment 8

[Daniel Holbert [:dholbert]]

(In reply to jedierikb from comment #7)

Firefox can render scalable vector graphics (svg) with large dimensions, so it would seem a good idea to extend this rendering functionality to the css background-image.

Yeah - this issue arises from a limitation of how we draw static images (using an intermediate surface, to e.g. optimize repaint operations) vs. how we draw actual top-level document content (painting directly to the screen). This is possible to fix, but it's not as simple as just extending some rendering functionality from one case to another.

This way designers can more clearly express themselves using your engines.

Could you help us understand your particular use-case? (What's the purpose of creating such extremely-large SVG images, and then only snipping out a small square in a background-image?)

Comment 9

[Timothy Nikkel (:tnikkel)]

Something like a sprite sheet maybe?

Comment 10

[Andrew Osmond [:aosmond] (he/him)]

Bug 1704792 won't solve this as is, but puts on the road to being able to, since it will let us rasterize in tiles, and in this case, it would only need to rasterize the first tile.

Comment 11

[jedierikb]

Our SVG files are akin to architectural blueprints. These often have large display dimensions, but relatively small file sizes.

We also update the css property background-position to animate these backgrounds for stylistic effect.