Re: [whatwg] Canvas feedback (various threads)
On Thu, 10 Feb 2011, Boris Zbarsky wrote: On 2/10/11 11:31 PM, Ian Hickson wrote: I think you had a typo in your test. As far as I can tell, all WebKit-based browsers act the same as Opera and Firefox 3 on this: http://software.hixie.ch/utilities/js/canvas/?c.clearRect(0%2C%200%2C%20640%2C%20480)%3B%0Ac.save()%3B%0Atry%20%7B%0A%20%20c.strokeStyle%20%3D%20'red'%3B%0A%20%20c.fillText(c.strokeStyle%2C%2020%2C%2080)%3B%0A%20%20c.strokeStyle%20%3D%20'transparent'%3B%0A%20%20c.fillText(c.strokeStyle%2C%2020%2C%20120)%3B%0A%7D%20finally%20%7B%0A%20%20c.restore()%3B%0A%7D%0A On that test, Safari 5.0.3 on Mac outputs red and transparent for the two strings. Huh. Interesting. I never test release browsers, totally missed this. :-) Thanks. Which is less interop than it seems (due to Safari's behavior), and about to disappear completely, since both IE9 and Firefox 4 will ship with the 0 instead of 0.0 :( Is there no chance to fix this in Firefox 4? It _is_ a regression. :-) At this point, probably not. If it's not actively breaking websites it's not being changed before final release. If it is, we'd at least think about it... Well I don't really mind what we do at this point. I'm assuming you're not suggesting changing the alpha=1 case (which is also different between CSS and canvas). Is that right? I guess with IE9 and Firefox4 about to go to the 0 behaviour, and Safari still having 0 behaviour, and Opera and Chrome being the only ones doing what the spec says, we should move to 0... I've changed the spec to make alpha1 colours work like CSS, and I've marked this part of the spec as controversial so that people are aware that it could change again. I guess we'll look at the interop here again in a few months and see if it's any better. My apologies to Opera and WebKit for getting screwed by following the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canvas feedback (various threads)
On 2/11/11 3:34 PM, Ian Hickson wrote: I'm assuming you're not suggesting changing the alpha=1 case (which is also different between CSS and canvas). Is that right? Sadly, probably right. For the alpha=1 case, I would expect there to be sites depending on this... -Boris
Re: [whatwg] Canvas feedback (various threads)
On Thu, 3 Feb 2011, Boris Zbarsky wrote: It looks like CSS rgba colors with an alpha value of 0 are serialized as rgba() with 0 as the alpha value. in at least Gecko, Webkit, and Presto. It also looks like canvas style color with an alpha value of 0 are serialized as rgba() with 0.0 as the alpha value in Gecko 3.6, Webkit, and Presto. In Gecko 2.0 we made a change to the canvas code to fix some bugs in the serialization by the simple expedient of reusing the well-tested code that CSS colors use. This has the incidental benefit of more behavior consistency for authors. Unfortunately, this makes us not do what these other UAs do, nor do what the current spec draft says. While we can clearly special-case 0 in this code, it seems like an authoring pitfall to have the two different serialization styles, so I would prefer to have consistent behavior between the two. What do other UA vendors think of standardizing on 0 as the serialization for canvas color alpha channels when they're transparent? Alternately, what about using 0.0 for CSS colors? On Fri, 4 Feb 2011, Anne van Kesteren wrote: Either way is fine. Note however that when there is no alpha-channel involved the differences are much greater between CSS and canvas. At least in Gecko/WebKit. I.e. rgb() vs #rrggbb. That probably cannot be changed though. Given Anne's point (that this is already different in other contexts), and given the current deployed interop on this issue, I'm reluctant to change this. I agree that it's unfortunate that we needlessly differ from CSS here. It's another example of why it's important for us to define everything, and that we never leave anything up to UAs to decide. :-) On Mon, 17 Jan 2011, carol.sz...@nokia.com wrote: I propose changing the drawing model steps 2 to 5 the following way: Step 2: Multiply the alpha channel of every pixel in A by globalAlpha. (Prior Step 5) Step 3: When shadows are drawn, render the shadow from image A, using the current shadow styles, creating image B. Step 4: When shadows are drawn, composite image B onto image A using destination-over compositing operation. This algorithm is less expensive then the prior one (it saves one multiplication of the AlphaChannel over the entire B bitmap), and treats the image/object drawn and its shadow as one entity. Which results in the shadow being preserved for composite operations such as copy and source-in and produces less strange results in operations such as xor and destination-out when shadows are drawn. The this algorithm yields the same result as the current version of the spec for source-over, but for completeness supports shadows in all modes. Indeed the way the current spec exists, many non-source-over modes including xor yield very strange results if shadows are used. I do not care that much if the spec has my proposal in it or whether it specs that shadows are not rendered in modes other then source over, but it would be nice to hear an agreement from browser implementors on this. On Tue, 18 Jan 2011, Robert O'Callahan wrote: [...] if we don't have good use cases for using shadows with non-source-over operators (I don't), let's just say that shadows don't draw for non-source-over operators. That would reduce spec and implementation complexity. I'm happy to do either of these, but I'm very relunctant to change the spec away from what browsers do. Currently, browsers pretty much agree on how shadows work in composition, they just disagree over what gets composited (and even then it's only really WebKit that disagrees). If there is interest in changing this, I think the best thing would be for browser vendors to indicate a commitment to change it, so that I can make sure I'm not changing the spec away from what browsers want to implement. On Tue, 23 Nov 2010, Tab Atkins Jr. wrote: Right now, canvas gradients interpolate their colors in non-premultiplied space; that is, the raw values of r, g, b, and a are interpolated independently. This has the unfortunate effect that colors darken as they transition to transparent, as transparent is defined as rgba(0,0,0,0), a transparent black. Under this scheme, the color halfway between yellow and transparent is rgba(127,127,0,.5), a partially-transparent dark yellow, rather than rgba(255,255,0,.5).* The rest of the platform has switched to using premultiplied colors for interpolation, because they react better in cases like this**. CSS transitions and CSS gradients now explicitly use premultiplied colors, and SVG ends up interpolating similarly (they don't quite have the same problem - they track opacity separate from color, so transitioning from color:yellow;opacity:1 to color:yellow;opacity:0 gives you color:yellow;opacity:.5 in the middle, which is the moral equivalent of rgba(255,255,0,.5)). It would be unfortunate for canvas gradients to be the only
Re: [whatwg] Canvas feedback (various threads)
On Thu, Feb 10, 2011 at 4:56 PM, Ian Hickson i...@hixie.ch wrote: Looking at that demo, it seems that premultiplied removes possible options from the author. How do you go from red to actually transparent black, getting darker as you transition? Do you have to give a nearly-transparent black (alpha=0.01) to get around it or some such? That seems weird. If you want to mimic the appearance of red-transparent black in non-premultiplied space, then yes, you need to put in several additional color-stops. In premultiplied space, that transition is a curved path. It's not only the 'transparent' keyword; it affects all cases of gradients between colors with different alpha values and different color values. And in cases where one of the endpoint alphas is not 0, it's not possible to get the correct (premultiplied) result with a gradient computed in nonpremultiplied space. Can you elaborate on that? I'm interested in seeing the cases that you can't do in one or the other of the colour spaces we're discussing. If one is a strict superset of the other, then it would make sense to specify that we use that one. If you can do the same gradients in both, then interoperability seems more important. The two color-spaces are equivalent in terms of colors and gradients than can be expressed, though the ease of expressing certain gradients are different between them. CSS does transitions in premultiplied space, and both FF and Webkit are planning to do CSS gradients in premultiplied space as well (the spec already requires it). It would be unfortunate to have canvas work differently than CSS here. The canvas gradient spec is pretty uniformly and interoperably implemented on this front: http://software.hixie.ch/utilities/js/canvas/?c.clearRect(0%2C%200%2C%20640%2C%20480)%3B%0Ac.save()%3B%0Avar%20gradient%20%3D%20c.createLinearGradient(0%2C0%2C640%2C480)%3B%0Agradient.addColorStop(0%2C%20'rgba(255%2C255%2C255%2C1)')%3B%0Agradient.addColorStop(1%2C%20'rgba(0%2C0%2C0%2C0)')%3B%0Ac.fillStyle%20%3D%20gradient%3B%0Ac.fillRect(0%2C0%2C640%2C480)%3B%0Ac.restore()%3B%0A It's easy to work around this issue: http://software.hixie.ch/utilities/js/canvas/?c.clearRect(0%2C%200%2C%20640%2C%20480)%3B%0Ac.save()%3B%0Avar%20gradient%20%3D%20c.createLinearGradient(0%2C0%2C640%2C480)%3B%0Agradient.addColorStop(0%2C%20'rgba(255%2C255%2C255%2C1)')%3B%0Agradient.addColorStop(1%2C%20'rgba(255%2C255%2C255%2C0)')%3B%0Ac.fillStyle%20%3D%20gradient%3B%0Ac.fillRect(0%2C0%2C640%2C480)%3B%0Ac.restore()%3B%0A I'm happy to change the spec on this, but I'm not going to change it ahead of the implementations. If you want this changed, I recommend getting the browser vendors to change this. Ok. ~TJ
Re: [whatwg] Canvas feedback (various threads)
On Thu, 10 Feb 2011, Boris Zbarsky wrote: On 2/10/11 7:56 PM, Ian Hickson wrote: On Thu, 3 Feb 2011, Boris Zbarsky wrote: It looks like CSS rgba colors with an alpha value of 0 are serialized as rgba() with 0 as the alpha value. in at least Gecko, Webkit, and Presto. It also looks like canvas style color with an alpha value of 0 are serialized as rgba() with 0.0 as the alpha value in Gecko 3.6, Webkit, and Presto. I have to correct myself. The above is the behavior in _Chrome_, not in all Webkit-based browsers. In Safari, canvas style colors are serialized as the original string they were set to, apparently (so if you set it to 0.0 you get 0.0 back; if you set it to 0 you get 0 back, and if you set interoperability you get interoperability back...). I think you had a typo in your test. As far as I can tell, all WebKit-based browsers act the same as Opera and Firefox 3 on this: http://software.hixie.ch/utilities/js/canvas/?c.clearRect(0%2C%200%2C%20640%2C%20480)%3B%0Ac.save()%3B%0Atry%20%7B%0A%20%20c.strokeStyle%20%3D%20'red'%3B%0A%20%20c.fillText(c.strokeStyle%2C%2020%2C%2080)%3B%0A%20%20c.strokeStyle%20%3D%20'transparent'%3B%0A%20%20c.fillText(c.strokeStyle%2C%2020%2C%20120)%3B%0A%7D%20finally%20%7B%0A%20%20c.restore()%3B%0A%7D%0A An additional data point is that in the IE9 RC you get 0, just like in Firefox 4. Good to know. Which is less interop than it seems (due to Safari's behavior), and about to disappear completely, since both IE9 and Firefox 4 will ship with the 0 instead of 0.0 :( Is there no chance to fix this in Firefox 4? It _is_ a regression. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canvas feedback (various threads)
On Thu, Feb 10, 2011 at 8:39 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/10/11 11:31 PM, Ian Hickson wrote: I think you had a typo in your test. As far as I can tell, all WebKit-based browsers act the same as Opera and Firefox 3 on this: http://software.hixie.ch/utilities/js/canvas/?c.clearRect(0%2C%200%2C%20640%2C%20480)%3B%0Ac.save()%3B%0Atry%20%7B%0A%20%20c.strokeStyle%20%3D%20'red'%3B%0A%20%20c.fillText(c.strokeStyle%2C%2020%2C%2080)%3B%0A%20%20c.strokeStyle%20%3D%20'transparent'%3B%0A%20%20c.fillText(c.strokeStyle%2C%2020%2C%20120)%3B%0A%7D%20finally%20%7B%0A%20%20c.restore()%3B%0A%7D%0A On that test, Safari 5.0.3 on Mac outputs red and transparent for the two strings. And this test: http://software.hixie.ch/utilities/js/canvas/?c.clearRect(0%2C%200%2C%20640%2C%20480)%3B%0Ac.save()%3B%0Atry%20%7B%0A%20%20c.strokeStyle%20%3D%20'red'%3B%0A%20%20c.fillText(c.strokeStyle%2C%2020%2C%2080)%3B%0A%20%20c.strokeStyle%20%3D%20'orly%2C%20do%20you%20think%20so'%3B%0A%20%20c.fillText(c.strokeStyle%2C%2020%2C%20120)%3B%0A%7D%20finally%20%7B%0A%20%20c.restore()%3B%0A%7D%0A outputs red and orly, do you think so in the same browser. Does Safari on Mac behave differently from Safari on Windows here? The version of WebKit used by Safari 5.0.3 is rather antiquated at this point. Using the latest WebKit nightly build, or Chrome 10.0.648.45 dev (which has a significantly newer version of WebKit), I get #ff and rgba(0, 0, 0, 0.0) on the first test and #ff / #ff on the second. Presumably at some point Apple will release a new version of Safari that matches the behavior nightlies currently have. - James Which is less interop than it seems (due to Safari's behavior), and about to disappear completely, since both IE9 and Firefox 4 will ship with the 0 instead of 0.0 :( Is there no chance to fix this in Firefox 4? It _is_ a regression. :-) At this point, probably not. If it's not actively breaking websites it's not being changed before final release. If it is, we'd at least think about it... -Boris
Re: [whatwg] Canvas feedback (various threads)
On 2/10/11 11:54 PM, James Robinson wrote: The version of WebKit used by Safari 5.0.3 is rather antiquated at this point. Using the latest WebKit nightly build, or Chrome 10.0.648.45 dev (which has a significantly newer version of WebKit), I get #ff and rgba(0, 0, 0, 0.0) on the first test and #ff / #ff on the second. Presumably at some point Apple will release a new version of Safari that matches the behavior nightlies currently have. Ah, I see. My point stands: interoperability among UAs that users are using right now (which doesn't include webkit nightlies, but does include Chrome 9 which seems to have the new behavior) is just not there. -Boris
Re: [whatwg] Canvas feedback (various threads)
On Wed, 11 Aug 2010, Philip Taylor wrote: On Wed, Aug 11, 2010 at 9:35 PM, Ian Hickson i...@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
Re: [whatwg] Canvas feedback (various threads)
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 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 intended that section 4, The elements of HTML, with minor exceptions, should be displayable with Canvas, and operable with a minimal canvas+webapps profile. Exceptions include, but are not limited to: script, iframe, embed, object, and for some time, video and audio. There are minimal instances in the current spec, which prohibit this. For those instances, there are additional use cases, outside of 'completion', mainly having relevance to accessibility (a11y). 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. But I'm not requesting a discussion on various aspects of fonts. I'm pointing to the non-availability of one particular metric, as a blocking issue in my ability to keep a string of text on the same baseline. 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. I'm no newbie, I understand and appreciate your oversight on html 5 implementations, your flexibility in exploring new standards (like WebSRT), and your conscientious approach to managing a living document. You're making a slippery slope argument, I don't think it fits: I'd asked for one property to be added to the specs document; as an extension of the textBaseline attribute already in the document. It's implementation-time is minimal. It's part of my approach, to give weight to implementation time and scope. We need to expose baseline positioning somewhere Why? What's the use case? Implementing a browser isn't a sane use case, sorry. Continuing that discussion is not sane... Exposing the baseline position of inline data would allow for fine-grained positioning of elements and better control of interactivity with text. Currently, I can't use fillText with two separate font sizes, and underline them. The textBaseline attribute gets me close, but it's insufficient. 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 Your enthusiasm for the final convergence is charming. I made a poor generalization. Most of us do not want to see vendor-specific extensions which stick. Example: moz..transform = webkit..transform = transform = ...;
Re: [whatwg] Canvas feedback (various threads)
On 8/11/2010 1:35 PM, Ian Hickson wrote:
On Tue, 10 Aug 2010, Charles Pritchard wrote:
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.
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.
Having worked quite awhile with WebApps APIs, Canvas included, I've
concluded that HTML can be implemented within the web stack.
CSS, Canvas and DOM interfaces are sufficient to provide an HTML and SVG
user agent, and WebApps APIs associate well with the host environment.
To this date, there have been very issues that have blocked me from
implementing such agents.
It's my firm belief that the Web Apps specifications can and should be
proven complete. Hypertext and DOM manipulation are well tested, parsing
has been well documented. We should hold HTML5 elements to the same
standard: the WebApps API should be sufficient to implement HTML UI
elements. Canvas contexts are the de facto standard for painting to a
screen. If an HTML element or an SVG element can not be produced within
the Canvas API, the WebApps spec is deficient.
Currently, there's a deficieny in the interoperability of these
standards: Web Fonts, HTML Forms, CSS line boxes, and SVG text, in
relation to baseline positioning. It's not a canvas issue; it simply
came to light while I was using canvas.
I'm certain that you've not heard a browser vendor tell you that
returning additional font data would be costly, or take away valuable
resources. 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.
We need to expose baseline positioning somewhere; we typically have
start positions by checking directionality and getting the compute style
of the css box. There are some items in range selectors as well as
TextMetrics that can help in returning the positioning of glyphs within
a string. What we don't have are standard ways to access baseline
metrics. It's a one-way process, it is not currently exposed as a
scripting API. Lets fix it.
John Daggett has given me some constructive feedback; he let me know
that a string may be composed of several fonts, and that the condition
may effect metrics. This is why, he believes, returning baseline metrics
on a given font is not a complete solution. He recommended revising
TextMetrics in canvas. I provided an alternative solution, getting the
computed style of a string within an inline element. That is... using
document.createElement('span').textContent = 'complex string'; And
gathering the computed value of that span.
Some issues in the interoperability of Web Fonts and Canvas text APIs
still exist. I recommend implementing both solutions, adding baseline
metrics to TextMetrics in canvas,
and returning baseline attributes for CSS inline elements, as a computed
style.
This approach would avoid the interop issue I mentioned, and return
reliable information to scripting APIs across CSS, HTML and Canvas.
That information, about baseline positioning of text, could then be used
for various use cases. The computed information is already available to
browser vendors, and would be inexpensive to expose to existing APIs.
Nobody wants to see another vendor-specific extension; can we try to
form an agreement on this, so we can avoid that?
-Charles
Re: [whatwg] Canvas feedback (various threads)
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? I agree that it is confusing. But Ian had asked whether it is possible to implement the spec, as now written, incorrectly. I suspect that any implementation that did transformations wrong would violate the spec somewhere. I still think it is worth clarifying the spec, but by Ian's criteria, I suspect it is not strictly necessary. 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. But if you don't talk about the algebraic operations then you haven't really defined what a transformation is, have you? 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? I suppose it does. So to be complete, the spec would have to show the math required to transform a point (x,y) using the CTM. Are you suggesting that there is some way that the spec can be written generically without any assumptions about row vector or column vector format? Note that the matrix shown above already appears in the current version of the transform() method description. I don't see how to avoid picking one form or another unless you want to define a CTM as an array of 6 numbers and show the formulas for updating each of those numbers without referring to matrix multiplication at all. David -Boris
Re: [whatwg] Canvas feedback (various threads)
On 8/12/10 10:59 AM, David Flanagan wrote: But if you don't talk about the algebraic operations then you haven't really defined what a transformation is, have you? Given that the input is in coordinates, we need to talk about algebraic operations to define the transformation on vectors those coordinates produce. That is, we need a clear definition of what the output vector is given an input vector and a list of 6 numbers. But once we have that, composition of transformation can be described simply as composition (thinking of them as functions), without reference to algebraic manipulation of their particular matrix representations. I suppose it does. So to be complete, the spec would have to show the math required to transform a point (x,y) using the CTM. Yes, indeed. Are you suggesting that there is some way that the spec can be written generically without any assumptions about row vector or column vector format? No, I'm just saying that the definition of transform composition doesn't need to make such assumptions. Note that the matrix shown above already appears in the current version of the transform() method description. I don't see how to avoid picking one form or another unless you want to define a CTM as an array of 6 numbers and show the formulas for updating each of those numbers without referring to matrix multiplication at all. While that would be a viable course of action, I don't think there's a need for that. Defining the CTM as a matrix and defining how the 6 numbers produce the matrix and exactly how the matrix acts on vectors is fine; while it's actually a bit more text than the other it produces a simpler conceptual picture. -Boris
[whatwg] Canvas feedback (various threads)
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 ] [ 001 ] [ 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,
Re: [whatwg] Canvas feedback (various threads)
On Wed, Aug 11, 2010 at 9:35 PM, Ian Hickson i...@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.) -- Philip Taylor exc...@gmail.com
Re: [whatwg] Canvas feedback (various threads)
Ian Hickson wrote: On Mon, 19 Jul 2010, David Flanagan wrote: Even changing the argument names to neutral a,b,c,d,dx,dy would be better than what is there currently. Done. Thanks 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!) 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 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. David
Re: [whatwg] Canvas feedback (various threads)
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. :-) Drag-and-drop works just fine, it's covered by event.dataTransfer. Accessibility has been addressed through drawFocusRing amongst other techniques of including relevant HTML within the canvas tag. Undo logic is covered by the history state objects. Text selection visuals work using measureText and textBaseline bottom. OS tools are fairly out of spec, though I do understand the value of extending a dataTransfer API to assist with UA context menu hooks, such as spellcheck/autocomplete/grammar suggestions. That said, there's nothing in the way of implementing those features within an HTML app. Even offline, both can be accomplished via WebSQL. Perhaps there should be a discussion about dataTransfer and the context menu. 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. Perhaps completeness is a poor choice. I'm concerned about obstructions. At present, there are very few obstacles. CSS and Canvas have allowed me to create implementations of HTML Forms, CSS line boxes and SVG. Baseline positioning is an obstacle. I realize that SVG has an even-odd fill mode. This is something that can be converted, and is rarely used. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' Through CSS computed styles, or a canvas interface, I will get accessible baseline offsets. :-)
Re: [whatwg] Canvas feedback (various threads)
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. -Boris
