Closed stuartpb closed 7 years ago
I can definitely add fill color, stroke color, stroke width etc to the API if you just need to access the values, but with the way the renderer currently works, changing them won't actually update what the SVG looks like.
Why was this closed? There still isn't any access to these values. (Also, why can't they be set?)
Sorry bout that, meant to post that I added this to the future features roadmap
Changing SVGs in realtime in the renderer is going to be really slow, as vectors get converted into images before getting passed into pixi.js. I tried using two.js as the renderer instead (two.js supports changing SVGs while they're being rendered) but it was too slow.
So I'm sort of stuck on where to go on this.
This is pretty important and complicated so I've reopened this issue~
Why can't the SVGs just use the browser's native SVG rendering?
Going to close this for now, major engine changes are needed for this feature to work.
There's now a section in the roadmap on dynamic SVGs.
I still don't get why there needs to be a JS engine layer for the SVGs. Is there really a JS SVG renderer that's more efficient than the usually-hardware-accelerated SVG rendering provided by the browser?
The renderer uses pixi.js which does not support SVG. All SVGs get rendered to images before being sent to pixi. This makes everything really fast, but makes it so SVGs can't be updated on the fly without a big hit to performance :(
Looking at the documentation, it looks like there's no script access to the fill or stroke properties of paths. Is that right?