[whatwg] Canvas feedback (various threads)

[Ian Hickson]

On Wed, 11 Aug 2010, Philip Taylor wrote:
> On Wed, Aug 11, 2010 at 9:35 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Thu, 29 Jul 2010, Gregg Tavares (wrk) wrote:
> >> source-over
> >>    glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
> >
> > I tried searching the OpenGL specification for either glBlendFunc or 
> > GL_ONE_MINUS_SRC_ALPHA and couldn't find either. Could you be more 
> > specific regarding what exactly we would be referencing?  I'm not 
> > really sure I understand you proposal.
> 
> The OpenGL spec omits the "gl"/"GL_" prefixes - search for BlendFunc 
> instead. (In the GL 3.0 spec, tables 4.1 (the FUNC_ADD row) and 4.2 seem 
> relevant for defining the blend equations.)

Maybe I'm looking at the wrong specification, but I couldn't find any 
conformance requirements in the document I read on any of the pages that 
contain BlendFunc:

   http://www.opengl.org/registry/doc/glspec40.core.20100311.pdf

If there's specific text you would like to have in the HTML specification 
to replace the current definitions, I'm happy to use it. I've been unable 
to work out what such text should be, however.


On Wed, 11 Aug 2010, David Flanagan wrote:
> 
> I think that the sentence "The transformations must be performed in 
> reverse order" is sufficient to remove the ambiguity in multiplication 
> order.  So the spec is correct (but confusing) as it stands, except that 
> it doesn't actually say that the CTM is to be replaced with the product 
> of the CTM and the new matrix.  It just says multiply them.
> 
> I suggest changing the description of transform() from:
> 
> > must multiply the current transformation matrix with the matrix 
> > described by:
> 
> To something like this:
> 
> must set the current transformation matrix to the matrix obtained by 
> postmultiplying the current transformation matrix with this matrix:
> 
> a c e
> b d f
> 0 0 1
> 
> That is:
> 
>              a c e
> CTM = CTM *  b d f
>              0 0 1

I tried to update the text a little, but I didn't explicitly say 
"postmultiplying", since saying that you multiple A by B seems less 
ambiguous to me than saying that you postmultiply A with B or that the 
result should be A * B (in the latter two cases you'd have to define 
"postmultiply" and "*" respectively).


> Changing translate(), scale() and rotate() to formally define them in 
> terms of transform() would be simple, and the current prose descriptions 
> of the methods could then be moved to the non-normative green box.  The 
> current descriptions suffer from the use of the word "add" near the word 
> "matrix" when in fact a matrix multiplication is to be performed, but I 
> don't think they can be mis-interpreted as they stands. I'd be happy to 
> write new method descriptions if you want to tighten things up in this 
> way, however.

I'm happy with the text as it stands if it's unambiguous, but if you have 
any specific proposed text let me know and I'll see if it is better. :-)


On Wed, 11 Aug 2010, Boris Zbarsky wrote:
> On 8/11/10 5:42 PM, David Flanagan wrote:
> > I think that the sentence "The transformations must be performed in 
> > reverse order" is sufficient to remove the ambiguity in multiplication 
> > order.
> 
> It is?  It sounds pretty confusing to me... reverse from what?
> 
> The right way to specify what happens when composing two transformations 
> is to just explicitly say which transformation is applied first, instead 
> of talking about the algebraic operations on the matrix representations.  
> In my opinion.

Yeah, I'm not sure it's perfect as is either. If anyone has any suggested 
improvements for the text please do propose it. I'm happy to massage it 
into RFC2119-speak; unfortunately my understanding of the maths and 
graphics here is not sufficient for me to write the actual requirements.


> > must set the current transformation matrix to the matrix obtained by 
> > postmultiplying the current transformation matrix with this matrix:
> > 
> > a c e
> > b d f
> > 0 0 1
> 
> See, that makes inherent assumptions about row vs column vectors that 
> aren't stated anywhere, right?

Yes, and that assumption has in fact bitten us in the behind before.


On Wed, 11 Aug 2010, Boris Zbarsky wrote:
> On 8/11/10 4:35 PM, Ian Hickson wrote:
> > On Mon, 19 Jul 2010, Boris Zbarsky wrote:
> > > 
> > > I do think the spec could benefit from an example akin to the one in 
> > > the CoreGraphics documentation.
> > 
> > I followed your references but I couldn't figure out which example you 
> > meant. What exactly do you think we should add?
> 
> Effectively the part starting with the second paragraph under 
> "Discussion" at 
> http://developer.apple.com/mac/library/documentation/GraphicsImaging/Reference/CGAffineTransform/Reference/reference.html#//apple_ref/doc/c_ref/CGAffineTransform 
> and going through the two linear equations defining x' and y'.  Plus a 
> bit that says how the linear list of arguments passed to transform() 
> maps to the 2-dimensional array of numbers in the transformation matrix.

I assume you mean the discussion in the definition of "struct 
CGAffineTransform"? I'm not confident enough about my understanding of 
this topic to be able to write prose conveying the same information 
accurately in the context of HTML. If you could provide text for this, I'd 
be more than happy to add such text to the spec.


On Sun, 3 Oct 2010, Charles Pritchard wrote:
> 
> Having worked quite awhile with WebApps APIs, Canvas included, I've 
> concluded that HTML can be implemented within the web stack.

It's definitely not the case, since if that were possible you would have 
exposed all kinds of security problems. :-) For example, you can't use the 
Web stack to send arbitrary content to a printer device (needed to 
implement window.print()), or to open arbitrary sockets (needed to 
implement any networking protocols), or to open arbitrary new windows 
(needed to implement window.open()), etc.

But I don't know why it would matter either way. Doing so would be an 
exercise in futility. :-)


> It's my firm belief that the Web Apps specifications can and should be 
> proven complete.

If by "complete" you mean "self-hosting", then: why? That seems like a 
very arbitrary goal.

If not, what do you mean?


> I'm concerned that the issue is being avoided because it originated from 
> a project you disagree with; and has biased your judgment of additional 
> use cases or possible remedies.

Good lord no. This is merely a prioritisation issue. I'm sure we'll add 
lots of metrics over time.

The problem is that anytime we add anything to canvas, implementors get so 
excited that they drop what they're doing and implement it (in some cases, 
overnight!). This takes resources away from other features. If we're to 
get the whole platform to improve, we need to make sure that everything 
gets a chance to be implemented. This means we can't just be adding stuff 
to canvas all the time.


> We need to expose baseline positioning somewhere

Why? What's the use case? Implementing a browser isn't a sane use case, 
sorry.


> Nobody wants to see another vendor-specific extension; can we try to 
> form an agreement on this, so we can avoid that?

On the contrary, we _do_ want to see vendor-specific extensions. That's 
how we get implementation experience and how the Web improves.

Standardisation is the penultimate stage in a feature's development, after 
studying author practices, experimental implementations in vendor-specific 
features, and studying use cases, and ahead only of the final convergence 
of browser implementations.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'