Re: [webkit-dev] Adding blending mode to WebKit canvas
On Wed, Nov 14, 2012 at 1:37 PM, Maciej Stachowiak m...@apple.com wrote: On Nov 14, 2012, at 8:33 AM, Rik Cabanier caban...@gmail.com wrote: On Tue, Nov 13, 2012 at 11:19 PM, Maciej Stachowiak m...@apple.com wrote: On Nov 13, 2012, at 4:43 PM, Rik Cabanier caban...@gmail.com wrote: Maciej, did this sound reasonable to you? Still doesn't make sense to me. Even if we don't implement CSS 'alpha-compositing' and 'blend-mode' today, I assume we will want to implement them eventually. At that point we will want them consistent with Canvas. If the only reason to combine compositing operator and blend modes is short-term ease of implementation on Mac, then that doesn't seem like a great reason to make the Web platform permanently inconsistent. Would you object if Canvas combines blending and compositing but not CSS? Yes. I think they should be consistent and the relevant standards group (FX Task Force?) should decide. It's not even very important to me which is chosen. It just seems arbitrary that they would make different choices on this, especially when it is all defined in the same spec. Thanks Maciej! I will bring this up on the FX mailing list. Depending on the outcome, I will amend the compositing spec. Thanks, that would be much appreciated. Hi Maciej, I send the question to the fx list. Tab Atkins brought up that we could extend the 'globalCompositeOperator' so it also takes a comma separate list of a blend and a compositing operation. Calling: mycontext.globalCompositeOperator = 'multiply'; would be identical to: mycontext.globalCompositeOperator = 'multiply, source-over'; This would make Canvas support blending and compositing and can be implemented with no compatibility issues later. Does this ease your concern about the difference between Canvas and CSS? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding blending mode to WebKit canvas
On Nov 14, 2012, at 5:19 PM, Rik Cabanier caban...@gmail.com wrote: I send the question to the fx list. Tab Atkins brought up that we could extend the 'globalCompositeOperator' so it also takes a comma separate list of a blend and a compositing operation. Calling: mycontext.globalCompositeOperator = 'multiply'; would be identical to: mycontext.globalCompositeOperator = 'multiply, source-over'; This would make Canvas support blending and compositing and can be implemented with no compatibility issues later. Does this ease your concern about the difference between Canvas and CSS? That still seems inconsistent between canvas and CSS to me. CSS will have two completely separate properties, not one that takes a comma-separated list, right? Why is one attribute with a comma-separated list superior for canvas but two properties are superior for CSS? Other concerns: - Taking a comma-separated list misleadingly implies that it can have an arbitrary number of components in arbitrary order, which is not the case. - Compared to having a separate property, this makes it hard to feature-test whether blend modes are supported. I can join the fx list to discuss this directly if you think that would help. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding blending mode to WebKit canvas
Maciej, did this sound reasonable to you? Would you object if Canvas combines blending and compositing but not CSS? Rik On Mon, Nov 12, 2012 at 3:46 PM, Rik Cabanier caban...@gmail.com wrote: On Mon, Nov 12, 2012 at 12:14 PM, Maciej Stachowiak m...@apple.com wrote: On Nov 11, 2012, at 9:06 PM, Rik Cabanier caban...@gmail.com wrote: On Sun, Nov 11, 2012 at 8:43 PM, Maciej Stachowiak m...@apple.com wrote: On Nov 11, 2012, at 6:59 PM, Rik Cabanier caban...@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. 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. Doesn't this same argument apply to CSS blend modes? (And therefore the 'blend-mode' and 'alpha-compositing' properties should be combined into a single property)? Yes, except I'm not proposing that we implement the 'alpha-compositing' property yet. I hope that MacOS (or Safari) can evolve in the future so it can be implemented more easily. Compositing in CSS is actually a much harder problem than in Canvas because it requires the UA to keep track of the 'shape'. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding blending mode to WebKit canvas
On Nov 13, 2012, at 4:43 PM, Rik Cabanier caban...@gmail.com wrote: Maciej, did this sound reasonable to you? Still doesn't make sense to me. Even if we don't implement CSS 'alpha-compositing' and 'blend-mode' today, I assume we will want to implement them eventually. At that point we will want them consistent with Canvas. If the only reason to combine compositing operator and blend modes is short-term ease of implementation on Mac, then that doesn't seem like a great reason to make the Web platform permanently inconsistent. Would you object if Canvas combines blending and compositing but not CSS? Yes. I think they should be consistent and the relevant standards group (FX Task Force?) should decide. It's not even very important to me which is chosen. It just seems arbitrary that they would make different choices on this, especially when it is all defined in the same spec. Regards, Maciej Rik On Mon, Nov 12, 2012 at 3:46 PM, Rik Cabanier caban...@gmail.com wrote: On Mon, Nov 12, 2012 at 12:14 PM, Maciej Stachowiak m...@apple.com wrote: On Nov 11, 2012, at 9:06 PM, Rik Cabanier caban...@gmail.com wrote: On Sun, Nov 11, 2012 at 8:43 PM, Maciej Stachowiak m...@apple.com wrote: On Nov 11, 2012, at 6:59 PM, Rik Cabanier caban...@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. 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. Doesn't this same argument apply to CSS blend modes? (And therefore the 'blend-mode' and 'alpha-compositing' properties should be combined into a single property)? Yes, except I'm not proposing that we implement the 'alpha-compositing' property yet. I hope that MacOS (or Safari) can evolve in the future so it can be implemented more easily. Compositing in CSS is actually a much harder problem than in Canvas because it requires the UA to keep track of the 'shape'. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding blending mode to WebKit canvas
On Nov 11, 2012, at 10:09 PM, Rik Cabanier caban...@gmail.commailto:caban...@gmail.com wrote: On Sun, Nov 11, 2012 at 9:52 PM, Dirk Schulze k...@webkit.orgmailto:k...@webkit.org wrote: On Sunday, November 11, 2012, Rik Cabanier wrote: On Sun, Nov 11, 2012 at 8:43 PM, Maciej Stachowiak m...@apple.com wrote: On Nov 11, 2012, at 6:59 PM, Rik Cabanier caban...@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. Is this the 'darker' compositing mode or are there others? Lighter and darker, yes. Greetings Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding blending mode to WebKit canvas
On Nov 9, 2012, at 4:39 PM, Rik Cabanier caban...@gmail.com wrote: Hi, I'd like to add support for blending modes to Canvas. The spec for this feature can be found here: https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#canvascompositingandblending The implementation will be tracked by a meta bug: https://bugs.webkit.org/show_bug.cgi?id=100069 I also attached a large patch that shows how this feature can be implemented. Looking at your patches on bug 100069 and bug 101804, I actually have some questions. If I understand your API changes correctly, the 'globalCompositeOperation' property gets more keywords. The new keywords will be the same as for the 'blend-mode' property of the CSS Compositing spec. Does it mean that blend mode always will use the compositing operator 'source-over'? The example implementation of GraphicsContext::setPlatformCompositeOperation on CG indicates that it would be possible to combine blend modes with different compositing operators in CG already. If you set both with the same property 'globalCompositeOperation', it won't be possible to mix them in the future. If more implementations are capable to support mixing alpha compositing and blending, the property can not be changed anymore. 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'. Btw. why is this addition in CSS Compositing and not in the Canvas spec? Greetings, Dirk Please let me know of any concerns. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding blending mode to WebKit canvas
On Sun, Nov 11, 2012 at 5:25 PM, Dirk Schulze dschu...@adobe.com wrote: On Nov 9, 2012, at 4:39 PM, Rik Cabanier caban...@gmail.com wrote: Hi, I'd like to add support for blending modes to Canvas. The spec for this feature can be found here: https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#canvascompositingandblending The implementation will be tracked by a meta bug: https://bugs.webkit.org/show_bug.cgi?id=100069 I also attached a large patch that shows how this feature can be implemented. Looking at your patches on bug 100069 and bug 101804, I actually have some questions. If I understand your API changes correctly, the 'globalCompositeOperation' property gets more keywords. The new keywords will be the same as for the 'blend-mode' property of the CSS Compositing spec. Does it mean that blend mode always will use the compositing operator 'source-over'? Correct. From the spec [1]: Blending is not separated from compositing in canvas 2d. If a blend operation is selected its results must always be composited with the ‘ source-over’https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#porterduffcompositingoperators_srcover compositing mode. The example implementation of GraphicsContext::setPlatformCompositeOperation on CG indicates that it would be possible to combine blend modes with different compositing operators in CG already. Unfortunately, CG can't do this (yet). The code is written to minimize change and to make this split easy to implement in the future. If you set both with the same property 'globalCompositeOperation', it won't be possible to mix them in the future. If more implementations are capable to support mixing alpha compositing and blending, the property can not be changed anymore. Well, it can still be changed. If in the future, people feel the need to specify blending and compositing separately, we can define a new property (globalBlendOperation?) that specifies the blending operation before globalCompositeOperation. If a user specifies a blending operation in both globalBlendOperation and globalCompositeOperation, we can define that globalCompositeOperation reverts to source-over. 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... Btw. why is this addition in CSS Compositing and not in the Canvas spec? I got feedback that it was best to specify this in the compositing spec since it explains in detail how the formulas work and has pretty pictures. The canvas spec can be changed to refer to the blending spec. Rik 1: https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#canvascompositingandblending ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding blending mode to WebKit canvas
On Nov 11, 2012, at 6:59 PM, Rik Cabanier caban...@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. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding blending mode to WebKit canvas
On Sun, Nov 11, 2012 at 8:43 PM, Maciej Stachowiak m...@apple.com wrote: On Nov 11, 2012, at 6:59 PM, Rik Cabanier caban...@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. 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. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding blending mode to WebKit canvas
On Sunday, November 11, 2012, Rik Cabanier wrote: On Sun, Nov 11, 2012 at 8:43 PM, Maciej Stachowiak m...@apple.comjavascript:_e({}, 'cvml', 'm...@apple.com'); wrote: On Nov 11, 2012, at 6:59 PM, Rik Cabanier caban...@gmail.comjavascript:_e({}, 'cvml', 'caban...@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. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding blending mode to WebKit canvas
On Sun, Nov 11, 2012 at 9:52 PM, Dirk Schulze k...@webkit.org wrote: On Sunday, November 11, 2012, Rik Cabanier wrote: On Sun, Nov 11, 2012 at 8:43 PM, Maciej Stachowiak m...@apple.com wrote: On Nov 11, 2012, at 6:59 PM, Rik Cabanier caban...@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. Is this the 'darker' compositing mode or are there others? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Adding blending mode to WebKit canvas
Hi, I'd like to add support for blending modes to Canvas. The spec for this feature can be found here: https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#canvascompositingandblending The implementation will be tracked by a meta bug: https://bugs.webkit.org/show_bug.cgi?id=100069 I also attached a large patch that shows how this feature can be implemented. Please let me know of any concerns. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev