- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 11 Aug 2010 20:35:39 +0000 (UTC)
On Mon, 19 Jul 2010, David Flanagan wrote:
> The spec describes the transform() method as follows:
> >
> > The transform(m11, m12, m21, m22, dx, dy) method must multiply the
> > current transformation matrix with the matrix described by:
> >
> > m11 m21 dx
> > m12 m22 dy
> > 0 0 1
>
> The first number in these argument names is the column number and the
> second is the row number. This surprises me, and I want to check that
> it is not an inadvertent error:
>
> 1) Wikipedia says (http://en.wikipedia.org/wiki/Matrix_multiplication)
> that the convention is to list row numbers first
>
> 2) Java's java.awt.geom.AffineTransform class also lists the row index
> first, as in the following javadoc excerpt:
>
> > [ x'] [ m00 m01 m02 ] [ x ] [ m00x + m01y + m02 ]
> > [ y'] = [ m10 m11 m12 ] [ y ] = [ m10x + m11y + m12 ]
> > [ 1 ] [ 0 0 1 ] [ 1 ] [ 1 ]
>
> It would be nice if this spec was not inconsistent with other usage.
> Even changing the argument names to neutral a,b,c,d,dx,dy would be
> better than what is there currently.
Done.
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?
On Tue, 20 Jul 2010, Yp C wrote:
>
> But I think the number can indicate the position of the value in the
> matrix,if change them into "a,b,c..." like cairo, I think it will still
> confuse the beginner.
The a,b,c,... notation is at least as common as m11,m12,....
On Mon, 19 Jul 2010, Brendan Kenny wrote:
>
> Looking at that last CoreGraphics link, it seems like the current names
> are an artifact of a row-vector matrix format (in which 'b' *is* m12)
> that is transposed for external exposure in the browser, but retains the
> same entry indexing.
Yes.
> The row- vs column-vector dispute is an ancient one, but I can't think
> of anyone that refers to an entry of a matrix by [column, row].
It appears at least .NET uses the same notation and order.
On Mon, 19 Jul 2010, David Flanagan wrote:
>
> While I'm harping on the transform() method, I'd like to point out that
> the current spec text "must multiply the current transformation matrix
> with the matrix described by..." is ambiguous because matrix
> multiplication is not commutative. Perhaps an explicit formula that
> showed the order would be clearer.
>
> Furthermore, if the descriptions for translate(), scale() and rotate()
> were to altered to describe them in terms of transform() that would
> tighten things up.
Could you describe what interpretations of the current text would be valid
but would not be compatible with the bulk of existing implementations? I'm
not sure how to fix this exactly. (Graphics is not my area of expertise,
unfortunately. I'm happy to apply any proposed text though!)
On Tue, 20 Jul 2010, Andreas Kling wrote:
> Greetings!
>
> The current draft of HTML5 says about rendering radial gradients:
>
> "This effectively creates a cone, touched by the two circles defined in
> the creation of the gradient, with the part of the cone before the start
> circle (0.0) using the color of the first offset, the part of the cone
> after the end circle (1.0) using the color of the last offset, and areas
> outside the cone untouched by the gradient (transparent black)."
>
> I find this behavior of "transparent spread" rather strange and it
> doesn't match any of the SVG gradient's spreadMethod options.
>
> The sensible behavior here IMO is "pad spread" (SVG default, and what
> most browsers implementing <canvas> currently do) which means repeating
> the terminal color stops indefinitely.
I'm pretty sure it's too late to change this.
On Wed, 28 Jul 2010, David Flanagan wrote:
>
> Firefox and Chrome disagree about the implementation of the
> destination-atop, source-in, destination-in, and source-out compositing
> operators. [...]
>
> I suspect, based on the reference to an "infinite transparent black
> bitmap" in 4.8.11.1.13 Drawing model that Firefox gets this right and
> Chrome gets it wrong, but it would be nice to have that confirmed.
>
> I suggest clarifying 4.8.11.1.3 Compositing to mention that the
> compositing operation takes place on all pixels within the clipping
> region, and that some compositing operators clear large portions of the
> canvas.
On Wed, 28 Jul 2010, Tab Atkins Jr. wrote:
>
> The spec is completely clear on this matter - Firefox is right,
> Chrome/Safari are wrong. They do it wrongly because that's how
> CoreGraphics, their graphics library, does things natively.
On Wed, 28 Jul 2010, Oliver Hunt wrote:
>
> This is the way the webkit canvas implementation has always worked,
> firefox implemented this incorrectly, and the spec was based off of that
> implementation.
Actually the spec was based off the WebKit implementation, but this
particular part had no documentation describing what it did, so I
couldn't specify it. :-(
On Fri, 30 Jul 2010, Robert O'Callahan wrote:
>
> As it happens, I'm expecting to see a proposal on public-canvas-api
> sometime soon that makes all composition source-bounded and has
> acceptable text defining the shape affected by the composition
> operation. It's tricky though, especially regarding shadows. But since I
> agree source-boundedness is more intuitive for authors, I'm open to
> changing Firefox to support it.
I'm happy to change the spec, so long as what the spec says is
well-defined.
On Thu, 29 Jul 2010, Leonardo Dutra wrote:
>
> *"**Composite **A** within the clipping region over the current canvas
> bitmap using the current composition operator."*
> *
> *
> The word "clipping" is the point. I am very sad that input type="color" does
> not cite the need of a color picker. But This part, is completely bright.
>
> That's why Microsoft agree with Chrome, Chrome with Safari (they don't agree
> sometimes) and Opera presents that way too.
>
> A hug.
I'm afraid I didn't understand this e-mail.
On Thu, 29 Jul 2010, Gregg Tavares (wrk) wrote:
>
> In that direction it would be nice if 2 things in the spec changed
>
> #1) Get rid of the "infinite transparent black bitmap" stuff and change
> it to something that say only pixels inside the shape/image are effected
Change it what, exactly?
> #2) Change the globalCompositingOperation spec from referencing PORTER-DUFF
> to referencing OpenGL
What problem would this solve?
> 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.
On Wed, 28 Jul 2010, David Flanagan wrote:
>
> I disagree that the spec is completely clear, however. In order to
> understand it you have to skip from section 3 on compositing operators
> to section 13 which mentions the infinite bitmap and compositing within
> the clipping region. There is no mention of the relevance of the
> clipping region in the section on compositing which seems like an
> oversight.
I've tried to clarify this.
> Also, descriptions of the operators cover only transparent and opaque
> pixels; they don't explain how compositing is done for translucent
> pixels, except by oblique reference to the Porter-Duff paper.
I've tried to make this less oblique.
On Thu, 29 Jul 2010, Charles Pritchard wrote:
>
> I was looking for a usable method of providing the user the option to
> paste the URL of an image resource, and load it for manipulation with
> Canvas.
The solution to that will be CORS, in due course, if the remote site has
opted-in to allowing it, or <input type=file>, if the user is to provide
any random URL.
On Wed, 4 Aug 2010, Chris Marrin wrote:
> >
> > What happens if you call getContext with the same contextID but
> > different attributes?
>
> Good question. It's addressed in
> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/WebGL-spec.html#2.1.
> It says that subsequent calls ignore the attributes. There is a
> getContextAttributes call on the context to return what attributes were
> actually set.
That seems reasonable.
I've made getContext() have an open-ended list of additional arguments,
and let contexts say what happens to them the first time. When the method
is called a second time, these arguments are ignored.
'2d' ignores the arguments.
On Thu, 5 Aug 2010, Kevin Ar18 wrote:
>
> First off, let me start with a question to see if maybe I missed
> something somewhere:
>
> Is it possible to create an SVG shape (say a hollow circle) that allows
> you to click through the invisible areas of the svg canvas to html
> objects underneath?
I believe Boris answered this sufficiently. Let me know if there's
anything still open here.
> As far as I know, there is no way to do this using the HTML5 spec.
Correct. You have to use the SVG and CSS specs. :-)
> Rationale: One of the greatest benefits I see in SVG is the way it can
> potentially be used to integrate with HTML pages and affect the visual
> layout in new ways. Unfortunately, the current SVG-HTML integration
> keeps the two quite separated.
Note that you really shouldn't be putting layout in the HTML file, even if
it's using SVG. The HTML file should be media-independent as much as
possible.
On Wed, 11 Aug 2010, Philip Taylor wrote:
> On Wed, Aug 11, 2010 at 12:23 AM, Ian Hickson <ian at hixie.ch> wrote:
> > I've updated the spec to have complete return true if the src is the
> > empty string.
>
> Some canvas methods (drawImage, createPattern) are defined in terms of
> the complete attribute ("If the image argument is an HTMLImageElement
> object whose complete attribute is false, [...] then the implementation
> must return without drawing anything."). Now that it can be true when
> the image doesn't have any image data, what should they do when passed
> such an image?
Fixed.
On Tue, 10 Aug 2010, Charles Pritchard wrote:
> >
> > I recommend not using <canvas> for text editing.
>
> I've worked on a substantial amount of code dealing with text editing.
> At present, the descent of the current font has been the only
> deficiency.
Well, there's also the way it doesn't interact with the OS text selection,
copy-and-paste, drag-and-drop, accessibility APIs, the browsers' undo
logic, the OS spell-checker and grammar-checker, the OS text tools like
"Search in Spotlight", and the i18n features like bidi handling. And
that's just for starters. :-)
> I feel that using Canvas to implement HTML5/CSS provides a quality proof
> of the completeness of the 2D API.
The 2D API isn't complete by a long shot, there's no difficulty in proving
that. It's not trying to be complete.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 11 August 2010 13:35:39 UTC