Re: [svgwg] [svg-native] Decide whether reusable graphical elements are needed (#689)

It’s probably worth making a distinction between the general principal vs any individual example.

In principle, we shouldn’t diverge too much from SVG proper, and the mechanism that SVG uses to represent patterns and gradients is to have an extra element (`<pattern>`, `<linearGradient>`) that is referenced by potentially many nodes. Inlining the contents of these nodes into every user of them would probably be too much of a departure from SVG. If we want to have these features, they should match SVG’s design for them, which is to say, be reusable.

Beyond general principle, it’s worth discussing each idea individually.

- **`<pattern>`**:  All 2D graphics libraries I know of have some facility for patterns, which seems to indicate they are a convenient concept. They can, however, be flattened into individual geometry. However, as the visual size of the pattern shrinks, the file size of the flattened pattern grows proportionately. We implemented patterns in our OT-SVG rasterizer, and I believe it is impossible to implement on CoreGraphics without using SPI.
- **`<marker>`**: These should just be additional geometry. There’s no reason for them to exist in the document, because we are not preserving document semantics within the file.
- **`<symbol>` & `<use>`**: These should be considered together. They are tricky to implement correctly, but they are used in lots and lots of content. Presumably that’s a signal that they’re useful. It might be worth keeping the elements themselves, but not supporting all of their attributes (like `x=`).
- **Inner SVG**: This is significantly more difficult to implement than `<use>`, but I don’t think it gives you anything beyond what you already get with `<use>`.
- **Gradients Sharing Color Stops**: Not very difficult to implement, and it Illustrator uses it extensively, it’s probably worth supporting.
- **`<mask>`**: At least in CoreGraphics, implementing this requires making an offscreen drawing context and drawing into it. Each offscreen drawing context can use a significant amount of memory, either in main memory or on the GPU. These things can be nested, so the memory use could be quite significant, causing us to place artificial limits on how much we’ll mask. In addition, when making these offscreen contexts, we have to determine what the pixel density of the context should be (which might be nonuniform, if the content is under a perspective skew, for example). The masks can theoretically be flattened, but masking `n`-element geometry with an `m`-element mask would yield a `n*m`-element result, potentially causing the file size to explode. Also, implementing flattening would require using algorithms to perform path manipulation which are costly in performance, fuzzy in that they have magic epsilon thresholds which need to be tuned, and still the topic of ongoing academic research. **On the other hand**, every authoring tool I know of has some facility for masking, so the functionality is probably important. Masks are pretty common in lots of artwork around the world, but I don’t know how that translates into their use in existing SVG content.

-- 
GitHub Notification of comment by litherum
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/689#issuecomment-491619907 using your GitHub account

Received on Sunday, 12 May 2019 18:54:58 UTC