I'm working on Coleco Donkey Kong now... That one has a LOT of vector points all over the place (like 20 or 30 just to make a circle) Since it's mostly a couple of sprites used throughout, I'll fine tune those and just duplicate them all over. I'm curious if the in-MAME SVG renderer will work better with a few thousand less nodes to calculate...
Beware that I'm going to work on the renderer to make its output closer to inkscape's. Plus I know how to make all that fast, don't worry about the speed.
Just be aware that the slowness is probably as much NanoSVG's fault as it is the fault of the renderer backends. The latter is already solved for BGFX though, because if you flag the rasterized render primitives with PRIMFLAG_PACKABLE, the renderer backend will try to atlas anything <= 128x128 (and I can adjust that if you'd like) into a 1024x1024 texture atlas as it encounters it.
The atlas also preserves its contents across frames. I believe currently, if it attempts to add an atlasable texture to the atlas and fails, it will flush the atlas and re-atlas just the atlasable textures in this one frame. If that subsequently fails, it falls back to the old-and-slow method of creating a texture every frame. This has the downside that if your cached NanoSVG textures used in one frame can't be atlased, it will still be slow BGFX-side, but I can eventually fix that by making BGFX expand the atlas and flush it rather than just flushing.
