5 ms·

Just casually browsing the SVG spec[0] looks like it covers a lot of ground. Different coordinate systems, CSS styling, paths, clipping, filters, animations, sc

Just 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 ago
tf are you on, paths and clipping are essential.
gardaani 4y ago
SVG 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 ago
  I 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"?

easrng 4y ago

tf are you on, paths and clipping are essential.

gardaani 4y ago

SVG 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 ago
I 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"?