Replies: 1 comment 1 reply
-
As far as I know (I have the very same problem, but haven't yet had to do anything about it):
In our case, we use a bunch of glyphs for toolbar buttons, and if we dare use one somewhere else where it would show at 1024x1024, we get the 16x16 raster instead. I haven't found a way to create a specific size raster manually, that I can reuse with those macros, because they use the file's path (URI) as dictionary key. Discussions have happened around including the size in the key hashing, but that means that if you have a picture that resizes often -> you get hundreds/thousands of keys for that image at every size in between the range (and you have to keep them in memory). While I can't offer a solution to this, I too am curious about how we can deliver this and will follow this discussion closely if a solution emerges. A nice and clean API to rasterize svg to a specific size/ratio would be very welcome out of the box, but I'm afraid your suggested option to create (and manage) an atlas of Images from rasterized svgs at custom sizes seems to be the only solution at the moment. Edit: Mipmapping has been historically a solution to these problems, but that would be a decidedly larger feature to implement. |
Beta Was this translation helpful? Give feedback.
-
How can we avoid blurry horizontal and vertical lines in scaled SVGs?
Context: Our designer has drawn a set of SVG images with their horizontal and vertical paths on pixel boundaries (he uses Figma, which does this by default--the SVG path coordinates are all integers).
Our app loads these into
Image
widgets and scales them proportionately to the UI main window size, which needs to scale to fullscreen on displays from 1024x768 all the way up to 4k or 8k wall-mounted displays. At many window sizes (i.e. resolutions), there are scaling artifacts when horizontal and vertical lines don't align with the display grid.Example: Here is a zoomed-in example. The SVG has a path that's a filled white chevron placed over the ends of two abutted rectangles, one yellow and one grey. The dark line along the top of the yellow, white and grey areas is what I'm calling "scaling blur" (cluebat me if there's a proper term, thanks).
The reason the line spans the white area too is that the white chevron's blur is partially transparent, so the two rectangles' blurs show through. That line over the white area is the most important artifact to get rid of--it's ugly and distracting.
Idea: It seems like rasterizing to a texture at an integer multiple of the SVG's native resolution would prevent this kind of blur over the white area; then scaling the texture to the desired size when painting would only have "normal" scaling blur.
However, staring at the methods available on
Image
, that's clearly not the intent of that widget, and I'm lost wondering how to rasterize with an integer magnification from data compiled in via viainclude_image!()
orinclude_bytes!()
. Scaling and rendering the resulting texture seems like it should be easy.We could of course rasterize to .png and use
Image
, we prefer SVG so we can scale from 1024x768 all the way up to, say, 4k wall mounted-displays without huge pre-rasterized images compiled in, and get very crisp-looking text and shapes. We could also redraw the SVGs to avoid the kind of layering that causes this, but that's fragile because the designers would need to have that level of discipline for all SVGs they give us, forevermore.Is there a better approach? What APIs should I use to rasterize and (if it's not as obvious as it seems) scale & render?
Many thanks!
Beta Was this translation helpful? Give feedback.
All reactions