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

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.


>
>>
>>>
>>>> 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


>
>
>> 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.

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w