emilk
Proposal: SVGImage API that is separate from RetainedImage
Is your feature request related to a problem? Please describe. Currently, there is a problem with the current way SVGs are rendered: it is rasterized once, using the scale that the SVG file itself provides, and is reused regardless of render size.
This introduces various artifacts depending on resolution:
On low resolutions, ferris looks crunchy and not very smooth!
On high resolutions however, ferris looks low-detailed and pixelated.
Describe the solution you'd like I think a separate SVGImage struct, alongside RetainedImage, would be appropriate. This would store an initial pixmap for the size the SVG specifies, but would rasterize a new pixmap and cache it whenever one is requested for a resolution that does not yet exist. This may need some optimization / laziness however, because it might not be worth re-rasterizing SVGs if the size difference is only by a few pixels.
Describe alternatives you've considered Rasterizing a series of difference resolution pixmaps of SVGs and changing them as needed. This has the potential downside of more memory usage, but would be more performant.
Update: Seems like there's better ways to approach this, most likely to proceed by implementing mipmapping as well as providing a way for users to select a custom size to pre-render SVGs at.
I would like to see SVGs rendered as vectors rather than cached as bitmaps imho
Another problem with the current SVG implementation is that it is slow. Rasterizing 12 SVGs with a resolution of 100x100 pixels takes my computer around 2 seconds in debug mode and around 700ms in release mode.
Maybe tessellating the SVGs with lyon and rendering them as a mesh yields better performance?
