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

The SVG Working Group just discussed `[svg-native] Decide whether reusable graphical elements are needed`.

<details><summary>The full IRC log of that discussion</summary>
&lt;krit> topic: [svg-native] Decide whether reusable graphical elements are needed<br>
&lt;krit> GitHub: https://github.com/w3c/svgwg/issues/689<br>
&lt;krit> kris: we had this on the previous agenda but didn't cover all<br>
&lt;krit> myles: I think we had symbols, masks, gradients sharing stops and use.<br>
&lt;krit> AmeliaBR: we grouped  inner SVG with symbols<br>
&lt;krit> AmeliaBR: mask is still up for debate<br>
&lt;krit> myles: I think all implementations implementing masks use an offscreen buffwer<br>
&lt;krit> myles: so there are limitations like pixel density before drawing on a offscreen buffer and you need a big enough buffer which might be problematic on certain devices<br>
&lt;krit> myles: those are the pros.<br>
&lt;krit> s/pros/cons/<br>
&lt;krit> myles: The pros are that it is very common<br>
&lt;krit> AmeliaBR: I can not comment in general but on Blink they are similar<br>
&lt;krit> AmeliaBR: both are handled with compositing<br>
&lt;krit> some discussion about AA on clip path and masks<br>
&lt;AmeliaBR> > The raw geometry of each child element exclusive of rendering properties such as fill, stroke, stroke-width within a clipPath conceptually defines a 1-bit mask (with the possible exception of anti-aliasing along the edge of the geometry)<br>
&lt;AmeliaBR> from https://drafts.fxtf.org/css-masking-1/#ClipPathElement<br>
&lt;krit> krit: Masking draws a shape on an offscreen buffer which causes AA. Then this buffer is used with compositing which adds another level of AA. This is not allowed for clipping masks where only the clipped result (drawing the clipped content on the backdrop) is allowed to be anti-aliased<br>
&lt;krit> AmeliaBR: not normative in the spec though. We could agree that a clipping path is a vector operation.<br>
&lt;krit> myles: so the difference would be very suttle. Can it be tested?<br>
&lt;myles_> s/suttle/subtle/<br>
&lt;krit> krit: it is and we can not test it since AA depends on HW and SW implementation.<br>
&lt;krit> myles: I don't think that, if there are differences, they would matter for masking.<br>
&lt;krit> myles: As far as I know, there is no implementation that can use masking w/o an offscreen buffer.<br>
&lt;krit> AmeliaBR: reason I mentioned it is that the discussion should also be about clipping.<br>
&lt;krit> myles: most implementations implement clipping and masking differently. So implementation burden might differ. I would claim they do differ.<br>
&lt;krit> krit: just to add to the comment from myles: there might be implementations that implement masking and clipping the same way, there are implementations that don't.<br>
&lt;krit> krit: Do we know implementations that do not support masking?<br>
&lt;krit> myles: the MS one doesn't... let me verify<br>
&lt;krit> krit: I meant on the rendering level... D2D does support it, right?<br>
&lt;krit> krit: beside the argument of the offscreen buffer, all rendering implementations probably are able to support masking.<br>
&lt;myles_> https://docs.microsoft.com/en-us/windows/win32/direct2d/svg-support doesn't support masking<br>
&lt;krit> krit: the other question would be about the implementation complexity of &lt;mask> itself.<br>
&lt;krit> AmeliaBR: you mean the creation of a local coordinate system?<br>
&lt;krit> AmeliaBR: clipping path and patterns are similar to mask and have some kind of a local coordinate space though not all create a viewport with viewBox or similar<br>
&lt;krit> AmeliaBR: One option might be to support masks and clip path but only userSpaceOnUse or objectBoundingBox depending which one is easier to implement.<br>
&lt;krit> krit: I'd like us to get into this direction.<br>
&lt;krit> myles: So if we did accept masking then we would be asking MS to add masking to their implementation because they don't support it today.<br>
&lt;krit> myles: how would you implement masking with the streaming interface SVG Native Viewer has?<br>
&lt;krit> krit: Thinking about it it would be very difficult but should be possible<br>
&lt;krit> AmeliaBR: we all agree that clip path is necessary? So clip path will be part of SVG Native?<br>
&lt;krit> myles: I think this is right<br>
&lt;krit> AmeliaBR: so the question is about mask<br>
&lt;krit> myles: from an illustration point of view: how often do authors use masking?<br>
&lt;krit> krit: most content uses clipping path but there are cases where ppl use actual masking. For SVG Tiny export we rasterise it.<br>
&lt;krit> myles: we should get more feedback from implementers.<br>
&lt;krit> AmeliaBR: especially to discuss what is difficult about masking. myles could you open a new issue please?<br>
&lt;krit> myles: I'll do<br>
&lt;krit> myles: I think this is all for this bug<br>
</details>


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

Received on Monday, 29 July 2019 20:33:28 UTC