W3C home > Mailing lists > Public > www-style@w3.org > December 2013

Re: [css-compositing] Request to move Compositing and Blending spec to CR

From: Rik Cabanier <cabanier@gmail.com>
Date: Fri, 13 Dec 2013 21:12:32 -0800
Message-ID: <CAGN7qDAFPbqH2T70-0Xg1WKsS0rWHoAhHhCt776h3NdZZwrRPA@mail.gmail.com>
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>
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:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:17 UTC