Support scalable vector icons & patterns

[samanpwbb]

There's only mention of .png in the spec when talking about sprites. Can we support vector sprite formats like SVG? I would never want to use a bitmap as my sprite source what with the current state of device screen resolution.

[jfirebaugh]

SVG would be fine in mapbox-gl-js, where we can load it in an Image object and then render to a canvas to generate a raster at a given pixel ratio. Native platform support would likely be more iffy.

Current preference is for SDF images, which can be scaled and recolored, but of course don't support multiple colors.

See also #220.

[ljbade]

@jfirebaugh yeah would need a way to parse svg in native, but perhaps if we make a protobuf based vector format for simple sprites at least, then write a preprocessing tool to generate the protobuf files from svg for developers to use?

perhaps we just convert all svg into simple, points, lines and polygon with fixed vertices (ie no beizier curves etc)

[ljbade]

@jfirebaugh what is SDF? google is not giving me any relevant hits

[jfirebaugh]

I don't want to get into subsetting SVG or inventing our own vector graphics format. If we're going to support it, we should do so wholeheartedly using a robust rendering library provided by the platform.

SDF is signed distance fields which is what we use for text rendering. It's supported as an icon format as well.

[ljbade]

Oh so you mean, load SVG, render to bitmap, then copy to GL texture?

Hmm does Android directly support loading SVG, need to look into it. I know it does have a vector graphics rendering library.

[ljbade]

OK Android platform does not support SVG. We either need to use one of the numerous open source Android SVG libraries (and hope they are stable and fast), or roll our own SVG library.

[jfirebaugh]

Good to know @ljbade. That strongly suggests to me that we should not support SVG. I don't think we want to take on a built-in dependency on a SVG rendering library -- that would be very heavy.

[springmeyer]

I concur with @jfirebaugh's sentiment of doing this right or not at all and that doing it right is a serious effort that would be a distraction right now.

That said, I'll provide a bit more context. In the push to support SVG in Mapnik we found available dependencies at the time very heavy (like librsvg/cairo) so we rolled our own parser using boost::spirit and libxml2 and a custom renderer using AGG. Therefore we support only a subset of SVG, but a very useful subset for icons used in serverside rendering (where you don't need to worry about animations). https://github.com/memononen/nanosvg is an effort worth looking into since it is small and the author @memononen tailored if for use with OpenGL.

[ljbade]

@springmeyer I think nanosvg may be the way to go if we do want SVG support, directly rendering in OpenGL will be easier than trying to bake to bitmap on load and having to deal with scaling and rotation problems

[memononen]

Sorry to eavesdrop :) I thought, I'd share a few words about NanoSVG.

It was originally made to parse SVG files for game levels, it has grown over the years to support all kinds nasty svg things to parse, and more recently I added simple software rasterizer to it to be used to render sprites and icons. The rasterizer is not fully featured or super fast, but should be simple enough to extend when needed. In general it supports all kinds of shapes, solid and gradient fills and outlines (no dashes).

I also have another project called NanoVG (yeah, unfortunate naming), which is html canvas like renderer on top of OpenGL. I've tried to get the SVG rendering to work with it, but the quality is not there (nor speed). NanoVG uses the stencil trick to render complex polygons plus a 1px line for edge antialiasing. That method tends to create small but noticeable artifacts when you have tiny details because of the edge AA overdraw. If you use MSAA, then a OpenGL vector rendering at small size works fine.

There are number of tricks to get subpixel translation and rotation to work ok when using prerendered sprites/icons, scale is always tricky. One such trick is to render the image at 2x, then blur, and then render without mipmaps at half the size.

Multicolor SDF sounds like an interesting idea too (4 SDFs per texture sample! ;)).

[springmeyer]

@memononen Not eavesdropping at all - exactly why I mentioned you by name :) Thanks for the background and ideas!

[1ec5]

@samanpwbb clarified in chat that the main use case for the feature described in this issue is to have a style image scale cleanly using icon-size, whereas multiple screen resolutions can already be supported via separate @1x and @2x sprite sheets.

#581 is a related idea about leveraging the tooling around nine-part images that’s present on all the native platforms. Highway shields would benefit from either feature.

[lucaswoj]

Closing this as a "wontfix" for now. We can open a new ticket if there's a newfound pressing need or implementation concept.