RE: First draft of the blending and compositing spec

Hi Jeremie,

Appreciate you taking the time to review the draft.

From: Jeremie Patonnier [mailto:jeremie.patonnier@gmail.com]
Sent: Friday, 1 June 2012 4:20 AM
To: Rik Cabanier
Cc: public-fx@w3.org
Subject: Re: First draft of the blending and compositing spec

Hello,

I took the time to read this draft and I wish to thank you to push such a proposal. As an author, I dream of such feature available in the browser :D

Here are some thought about the draft. I'm not an expert in compositing and blending but I felt smart by reading this spec it's amazingly clear and understandable. Still, I saw things that puzzled me so here are they :

4.2 : This part really needs an example



I'll have a think about a good example and try to add something in to make it easier to understand.



4.3 : You say "knockout group" but the property is "knock-out". why are you using a dash for the property and not for the designation?


Excellent point, we'll go over and make sure we're consistent with this.
I think knockout, without the dash, would be the preferable choice.


I found unclear the way each element, inside the knockout group, is prioritized to determine which element knock-out which other one. It looks like it depend of the z-index of each element but it's not clearly stated. It could also be interpreted as dependent of the source code flow. In the end I presume it depend of the paint order define by each browser. The "knock-out" property definition does not really help much more here.


It is defined by the z order. I'll add some text somewhere to explicitly mention this.


5 : Even if it's "standard" to use the word destination when we are talking about Porter Duff stuff, it make the spec harder to read and understand. IMO it could be easier to chose a word ("backdrop" or "destination" whatever you prefer) and remain consistent all along the spec. It will avoid confusion.



I'd be happy to go with backdrop everywhere, except the operators have standard names that are well known, and those names include destination (e.g. dest-over).
This makes it tricky and is why I decided to use the word destination in the chapter and define destination as a synonym of backdrop.
I think that's less confusing than talking about backdrop in the text and using operator names with destination in them.
I don't think using destination everywhere is the right way to go.



I'm not an expert in compositing so, I do not understand what the 4 pixel subregions mean and the spec does not really help to understand this. As a consequence, the example looks wired and it's unclear to me why each pixel subregion is 25% in the example. I think it needs some clarification (at least for dumb author like me).


Hmmm, it's not an easy subject.
I do try to explain why each subregion is 25%. Maybe I haven't quite succeeded in making it fully approachable =)

Basically, in the example, because each object has half coverage (equivalent to 50% opacity) and there's always four regions, then in this case, the regions work out to be a quarter of the pixel each.
It's a theoretical model of the subpixel. The model has no knowledge of the actual subpixel layout so it defines a formula for the size of each sub-pixel, based on the coverage.
These formula are given in the table below the image.

Both = αa x αb
Source only = αa(1 - αb)
Destination only = αb(1 - αa)
None = (1 - αa)(1 - αb)

The sum of all areas equals 1.
So the more coverage each shape has, the more influence that shapes colour has to the final pixel value.
And if both shapes have high coverage then the combined area (both) has high influence and the individual areas (source, dest and none) have low influence.

This has some limitations and isn't always accurate, but it works pretty well.
To give you an example of an inaccuracy, if the shapes have half coverage each and abut without overlapping, the actual subpixel layout would look like

+-------+
|   |   |
| A | B |
|   |   |
+-------+

A is the area of the source shape
B is the area of the second shape

So you'd only really have 2 regions with any area and not four, but the model doesn't go into this level of detail.
The subpixel layout is only theoretical and not based on the actual subpixel layout.

As long as you understand the way the operators work in 5.1, the theory of where the subpixel regions come from isn't so vital.
Having said that, I'll go over it again and see if I can make it easier to understand.
Maybe a diagram showing some cases would help.

5.1.13 : A visual example will be helpful to understand the math

This is an oversight - there should be an example there

I think Rik has covered all the rest of the comments so I'll leave it at that.

Cheers
Nikos Andronikos
Canon Information Systems Research Australia Pty Ltd


The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.