[webkit-dev] Adding blending mode to WebKit canvas

[Dirk Schulze]

On Sunday, November 11, 2012, Rik Cabanier wrote:

>
>
> On Sun, Nov 11, 2012 at 8:43 PM, Maciej Stachowiak <mjs at apple.com<javascript:_e({}, 'cvml', 'mjs at apple.com');>
> > wrote:
>
>>
>> On Nov 11, 2012, at 6:59 PM, Rik Cabanier <cabanier at gmail.com<javascript:_e({}, 'cvml', 'cabanier at gmail.com');>>
>> wrote:
>>
>>
>>
>>
>>>
>>> Wouldn't it be better to add a new property to canvas for blending? At
>>> the beginning, implementations are just require to use different blend
>>> modes in combination with 'source-over'.
>>
>>
>> That could work too.
>> There was a mailing list conversation about this a couple of months ago,
>> and people were evenly split on the subject.
>>
>> The vast majority of cases will use 'source-over' in combination with
>> blending so maybe it's best to keep it simple...
>>
>>
>> It doesn't make sense to me for blend mode and composite operator to be
>> separate in CSS, but combined in Canvas. Either there are valid use cases
>> for specifying them separately or there are not. I cannot imagine how this
>> could differ between Canvas and CSS.
>>
>
To be fair, the 'globalCompositOperator' property mixed the compositing
modes with some blend modes already. Which is the fault of the WebKit
implementation. IIRC they have been removed from the Canvas part of the
HTML spec for some time, but were added later again. Now we have multiple
independent implementations that support all currently specified operators.

Greetings,
Dirk


>
>> There are cases where it makes sense to have them as separate properties.
> To be honest, the main reason that the Canvas proposal combines them, is
> because it is not possible to implement this efficiently using Core
> Graphics.
>
> If we break it up in 2 operations, we have to document the correct
> behavior (= blending does not force source-over for blending) because the
> spec can't be changed later.
> This means that Safari and Firefox for Mac can only implement part of the
> spec...
>
> I prefer to have a consistent implementation that can be extended later as
> opposed to a 'correct' API that is inconsistently implemented.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20121111/00ffa0ad/attachment.html>