3 ms·
"SVG is a horribly complex format and an overkill for most projects" Can this be given more substance..? Does it also apply to SVG v1.1 (Tiny/Basic)? It seems
by geokon 4y ago
"SVG is a horribly complex format and an overkill for most projects"
Can this be given more substance..?
Does it also apply to SVG v1.1 (Tiny/Basic)? It seems to cover a similarity limited scope. From the landing page its unclear if its fundamentally doing something different. In my naiive perspective itd seem more sensible to just make a new way to encode SVG?
- fbdab103 4y agoJust casually browsing the SVG spec[0] looks like it covers a lot of ground. Different coordinate systems, CSS styling, paths, clipping, filters, animations, scripting, fonts etc. There needs to be an open vector format that supports all of those things, but maybe it is inappropriate that this is what get shipped by default. [0]: https://www.w3.org/Graphics/SVG/1.1/ https://www.w3.org/Graphics/SVG/1.1/
- easrng 4y agotf are you on, paths and clipping are essential.
- gardaani 4y agoSVG Native was supposed to fix that [1]. SVG Native uses only one coordinate system, no CSS styling, no filters, no animation, no scripting and no text or fonts. However, it didn't get much interest and it's starting to look like a dead version of SVG. Maybe there isn't any need for a simpler vector graphics format because no one is using TinyVG, either. [1] https://w3c.github.io/svgwg/specs/svg-native/index.html https://w3c.github.io/svgwg/specs/svg-native/index.html
- geokon 4y ago“SVG Native is a subset of SVG 1.1, which removes animation, interactivity, linking, remote resource loading, scripting, and CSS ” So anyone who supports svg 1.1 supports this automatically. I guess it helpa define/narrow a small svg subset to target if you write a new renderer. For instance rendering with JavaFX primitives, this would maybe be achievable And this new thing also sounds kinda like a subset of svg..
- whitehexagon 4y agoI have been working on a Go/WASM canvas renderer for this subset, but the drawing overheads seem too high. I also tried rendering into WebGL, via creating an Image from a b64 encoded SVG. That works ok, until you try to manually (code, not CSS) animate any of the SVG attributes. Creating on the fly Images seems to leak memory (at least in FF) and trying to re-render into a texture seems to always involve a read-back. Overall not sure if I continue this route. Only Video seems to avoid the read-back, but are we supposed to render SVG into frames of video for efficient rendering? Of course I could inject into the DOM a 'naked' SVG, but it would be nice to find a route to use SVG via canvas or webgl. Maybe that would make the format more popular... But a binary format might be nice if rendering could be done via a shader :)
- scythe 4y ago>SVG Native was supposed to fix that [1]. [...] However, it didn't get much interest and it's starting to look like a dead version of SVG. It's pretty bad marketing to call a different product by the same name. Particularly when it chooses a totally different side of the trade-off versus its homonym. Not only have I never heard of SVG Native, I'm confident that I'm going to forget what it is in a few days because I don't have a proper name to remember it by. Also, the adjective "native" here gives me no useful information as to what problem it tries to solve — how do I infer "simplified" from "native"?