- From: Rik Cabanier <cabanier@gmail.com>
- Date: Fri, 13 Dec 2013 21:12:32 -0800
- To: "Robert O'Callahan" <robert@ocallahan.org>
- Cc: James Robinson <jamesr@google.com>, www-svg <www-svg@w3.org>, www-style list <www-style@w3.org>, "public-fx@w3.org" <public-fx@w3.org>
- Message-ID: <CAGN7qDAFPbqH2T70-0Xg1WKsS0rWHoAhHhCt776h3NdZZwrRPA@mail.gmail.com>
On Fri, Dec 13, 2013 at 8:51 PM, Rik Cabanier <cabanier@gmail.com> wrote: > > > > On Thu, Dec 12, 2013 at 11:38 PM, Robert O'Callahan <robert@ocallahan.org>wrote: > >> On Fri, Dec 13, 2013 at 6:36 PM, Rik Cabanier <cabanier@gmail.com> wrote: >> >>> On Thu, Dec 12, 2013 at 9:24 PM, Robert O'Callahan <robert@ocallahan.org >>> > wrote: >>> >>>> On Fri, Dec 13, 2013 at 4:50 PM, Rik Cabanier <cabanier@gmail.com>wrote: >>>> >>>>> On Thu, Dec 12, 2013 at 7:29 PM, Robert O'Callahan < >>>>> robert@ocallahan.org> wrote: >>>>> >>>>>> On Fri, Dec 13, 2013 at 4:13 PM, Rik Cabanier <cabanier@gmail.com>wrote: >>>>>> >>>>>>> No, the spec should not refer to blogs. Also, this is not >>>>>>> 'potentially' useful as the absence of this description has caused >>>>>>> confusion in the past. >>>>>>> >>>>>> >>>>>> I agree with James. Having the spec define behavior that is never >>>>>> used by any Web feature is very confusing. >>>>>> >>>>>> Section 4 is not really needed at all since the HTML5 canvas spec >>>>>> defines the canvas compositing behavior. >>>>>> >>>>> >>>>> Can you point where that is defined in the canvas spec? >>>>> >>>> >>>> >>>> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#drawing-model >>>> >>> >>> yes, that doesn't describe how you do the compositing. is it >>> 'clip-to-self', or the bounds of the drawing bitmap, or infinite bounds? >>> >> >> I think it's perfectly clear. >> >> 1. Render the shape or image onto an infinite transparent black bitmap, >>> creating image A, as described in the previous sections. For shapes, >>> the current fill, stroke, and line styles must be honored, and the stroke >>> must itself also be subjected to the current transformation matrix. >> >> 6. Composite A within the clipping region over the current scratch bitmap >>> using the current composition operator. >>> >> >> There's no practical difference between "bounds of the scratch bitmap" >> and "infinite bounds", and that's the behavior this text specifies. >> > > The text doesn't say what should happen with the area outside of A. A is > supposed to be infinite as well, but is generally not. > Correcting myself :-) Canvas does specify that both bitmaps are infinite so there's no need to call this out. Unfortunately, this is a change to the normative section of the spec so it needs to go for another last call... > >>>>> >>>>>> If you want the Compositing and Blending spec to define new >>>>>> compositing modes for canvas, then define a list of operators that the HTML >>>>>> canvas spec can refer to, but don't define globalCompositeOperation here. >>>>>> Don't even mention canvas here. >>>>>> >>>>> >>>>> It's needed because the canvas spec doesn't say anything about how >>>>> compositing should happen. >>>>> I don't want to break canvas by removing this. >>>>> >>>> >>>> All you need to define for canvas is the per-pixel compositing behavior. >>>> >>> >>> No. What if there are no pixels (ie with 'clear'), you'd still want to >>> clear that area. >>> >> >> Right. So for "clear" you just have to specify that the destination pixel >> is cleared. And that's what you do: >> http://dev.w3.org/fxtf/compositing-1/#porterduffcompositingoperators_clear >> > > Yes. It's cleared everywhere, even where there was no coverage/shape of A. > > >> >>> >>>> If a future spec will use it, the future spec can define it. >>>> >>> >>> No, we want to avoid defining the same thing over and over again. >>> Filters, blending, canvas, masking all need to build on a common model. >>> This is why we did the compositing and blending spec in the first place: >>> harmonize the different specs. >>> >> >> So define it in C&B level 2 if it's ever needed. Or move the operators to >> their own Compositing Operator spec. It still does not make sense to >> specify features that are not used anywhere in the Web platform. If W3C >> bureaucracy pushes us in that direction, let's push back. >> >> >>> >>>> Any use of clip-to-self will have to define what the clip-to-self >>>> region is for each drawing operation, which is not necessarily easy to do. >>>> It certainly shouldn't be done by saying the clip-to-self region is where >>>> alpha > 0, for the reasons James pointed out near the beginning of this >>>> thread. >>>> >>> >>> That is not what the spec says. clip-to-self=true works on the shape of >>> the element which is independent of its alpha. >>> >> >> OK, good. >> > > Thanks for pointing this out. When I compared with my reply with the > actual definition of clip-to-self and James' original objection, I realized > that the spec was wrong. > Given this, I will pull 'clip-to-self=true' out and rewrite the paragraph. >
Received on Saturday, 14 December 2013 05:13:04 UTC