Re: [whatwg] Support filters in Canvas
On Oct 1, 2014, at 12:28 PM, Mark Callow callow.m...@artspark.co.jp wrote:
On 30/09/2014 02:20, Markus Stange wrote:
Hi,
I'd like to revive this discussion.
On Sat, Mar 15, 2014 at 12:03 AM, Dirk Schulze
dschu...@adobe.com
wrote:
I would suggest a filter attribute that takes a list of filter operations
similar to the CSS Image filter function[1]. Similar to shadows[2], each
drawing operation would be filtered. The API looks like this:
partial interface CanvasRenderingContext2D {
attribute DOMString filter;
}
A filter DOMString could looks like: “contrast(50%) blur(3px)”
What happened to the effort to create CSS filters programmable in GLSL?
Wasn't that effort addressing canvas filters too? Programmable filters seem
more desirable than a fixed set. Last I heard the CSS filters effort was
exploring ways to limit filter operations to those that would not allow, for
example, the visited state of links to be determined. I think allowing
operations only on same-origin data solves those types of issues for canvas.
CSS Shaders are the programmable GLSL filters you mean. Some browser vendors
expressed their strong objection to this feature. We’ll explore the feature at
a later time. As you said, there were limitations in CSS Shaders that disallow
any direct pixel access. This makes it impossible to use CSS Shaders for many
use cases. Most of the short hand filters could not be done with CSS Shaders
for instance. However, shaders can still be used in WebGL on content without
privacy implications.
Greetings,
Dirk
Regards
-Mark
--
注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合が有ります。正式なメール受信者では無い場合はメール複製、
再配信または情報の使用を固く禁じております。エラー、手違いでこのメールを受け取られましたら削除を行い配信者にご連絡をお願いいたし ます.
NOTE: This electronic mail message may contain confidential and privileged
information from HI Corporation. If you are not the intended recipient, any
disclosure, photocopying, distribution or use of the contents of the received
information is prohibited. If you have received this e-mail in error, please
notify the sender immediately and permanently delete this message and all
related copies.G
Re: [whatwg] Support filters in Canvas
On Sep 30, 2014, at 6:45 AM, Rik Cabanier caban...@gmail.com wrote: On Mon, Sep 29, 2014 at 8:52 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Mon, Sep 29, 2014 at 2:12 PM, Rik Cabanier caban...@gmail.com wrote: Can we limit it to just the set of CSS filter shorthands for now? I think other UA's are further behind in their implementation of integrating SVG filters in their rendering pipeline. How about we put CSS + SVG filters into the one spec draft for now, and split them up into two drafts if we actually get to the point where vendors want to ship one and not the other? It seems premature to create both HTML Canvas Filters Level 1 and HTML Canvas Filters Level 2 at the same time. Are you proposing that this is developed as a separate spec and not as an addition to the canvas specification? I think it should be part of the canvas spec. I agree with Robert that it can be added to the spec initially. If it turns out that SVG Filters in canvas are to hard for implementations initially, then we can postpone it later. Greetings, Dirk
Re: [whatwg] Support filters in Canvas
Hi Markus,
Thanks for coming back with you implementation details. I think most of the
suggestions make sense overall but I’ll look at them in more detail, especially
regarding filter regions. Just a question to SVG filter references inline for
now.
On Sep 29, 2014, at 7:20 PM, Markus Stange msta...@themasta.com wrote:
Hi,
I'd like to revive this discussion.
On Sat, Mar 15, 2014 at 12:03 AM, Dirk Schulze dschu...@adobe.com wrote:
I would suggest a filter attribute that takes a list of filter operations
similar to the CSS Image filter function[1]. Similar to shadows[2], each
drawing operation would be filtered. The API looks like this:
partial interface CanvasRenderingContext2D {
attribute DOMString filter;
}
A filter DOMString could looks like: “contrast(50%) blur(3px)”
This approach sounds good to me, and it's what I've implemented for
Firefox in bug 927892 [1]. The Firefox implementation is behind the
preference canvas.filters.enabled which is currently off by default.
Filter functions include a reference to a filter element and a
specification of SVG filters[4]. I am unsure if a reference do an element
within a document can cause problems. If it does, we would just not support
SVG filter references.
I've included support for SVG filters in the Firefox implementation.
It's a bit of work and it increases the number of edge cases we need
to specify, but I think it's worth it.
Here's a more fleshed-out proposal that attempts to define the edge
cases I've encountered during development.
The ctx.filter property should behave like the ctx.font property in some
senses:
- It's part of the state of the context and honors ctx.save() and
ctx.restore().
- Setting an invalid value is ignored silently.
- Both inherit and initial are invalid values, as with font.
- Setting a valid value sets the current state's filter to that
value, and the getter will now return this value, possibly
reserialized.
Question: Do we want the getter to return the serialized form of the
filter? I don't really mind either way, and I'm not sure in what cases
the results would differ. I guess extraneous whitespace between
individual filter functions would be cleaned up, and 0 length values
would get set to 0px. Anything else?
- Resetting the state to no filtering is done using ctx.filter =
none. Values such as , null, or undefined are invalid and will be
ignored and not unset the filter.
Question: Is this what we want?
Filter rendering should work similarly to shadow rendering:
- It happens on every drawing operation, with the input to the filter
being what that operation would have rendered regularly.
- The transform of the context is applied during rendering of the
input. The actual filtering is not be subject to the transform and
happens in device space. This means that e.g. a drop-shadow(0px 10px
black) filter always offsets the shadow towards the bottom, regardless
of the transform.
- The results in the canvas pixel buffer will be the same regardless
of the CSS size of the canvas in the page, and regardless of whether
the canvas element is in the page at all or just a detached DOM node.
- The global composite operation is respected when compositing the
filtered results into the canvas contents. The filter input drawing
operation is always rendered with over into a conceptual transparent
temporary surface.
- The same applies for global alpha.
Interaction with shadow:
- If both a filter and a shadow are set on the canvas, filtering will
happen first, with the shadow being applied to the filtered results.
In that case the global composite operation will be respected when
compositing the result with shadow into the canvas.
- As a consequence of the other statements, this is true: If a valid
filter is used, appending drop-shadow(shadowOffsetXpx
shadowOffsetYpx shadowBlurpx shadowColor) to the filter will
have the same results as using the shadow properties, even if there is
a transform on the context.
Units:
- The CSS px unit refers to one canvas pixel, independent of the CSS
size of the canvas on the page. That is, a drop-shadow(0 10px black)
filter will have the same results in the canvas-internal pixel buffer,
regardless of whether that canvas is specified using canvas
width=100 height=100 style=width: 100px; height: 100px; or
canvas width=100 height=100 style=width: 20px; height: 20px;.
- Lengths in non-px units refer to the number of canvas pixels you
get if you convert the length to CSS px and interpret that number as
canvas pixels.
Font size relative units:
- Lengths in em are relative to the font size of the canvas context
as specified by ctx.font.
- The same applies for lengths in ex; and those use the x-height of
the font that's specified in ctx.font.
SVG filter specific considerations:
- Relative URLs in SVG filter reference url() functions are relative
to the canvas element (i.e. the base URL of the owner
Re: [whatwg] Move contentEditable/isContentEditable from HTMLElement to Element?
On Jul 2, 2014, at 4:01 AM, Ryosuke Niwa rn...@apple.com wrote: On May 15, 2014, at 10:01 AM, Elliott Sprehn espr...@chromium.org wrote: On Tue, May 13, 2014 at 11:21 AM, Ian Hickson i...@hixie.ch wrote: I would feel more comfortable putting things on SVG, MathML, and HTML explicitly. I don't think we want contenteditable in SVG or MathML. Almost all of the operations don't make sense. What does intending in SVG do? What does making something italic? What happens when you hit enter? We can't just insert a new line in SVG, does it add some space between all the shapes? Where does your caret actually appear? The question about “hitting enter” is valid. However, these kind of questions don’t seem to be clarified for HTML either. Every UA is doing something different. To the other questions: just text in text, textPath and tspan are affected. In all other cases the general processing rules of SVG apply. We might want some new kind of Web Editing API, but contenteditable/execCommand are both pretty specific to HTML. contenteditable isn't just for execCommand. We could simply enable plaintext editing inside SVG text element for example. However, I would like to know what use cases and problems Dirk is trying to solve by moving these attributes from HTMLElement to Element. Dirk, could you elaborate on that? If you add contentEditable to an HMTL element and an SVG element is an descendant of this element, SVG text is editable as well. If you add contentEditable to an SVGElement itself, it doesn’t work. That is an observation that can be see in all browsers IIRC. SVG folks actually get asked to support contentEditable. People want to use text along a path, have it selectable and editable. Just SVG can do that — but with the hack of above. Should we add contentEditable to SVGElement or Element seems to be the remaining question. This depends if there are similar scenarios in MathML (and other markup languages) as well. Greetings, Dirk - R. Niwa
Re: [whatwg] SVG cloning elements from HTML5
On Jun 24, 2014, at 5:25 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Thu, Jun 19, 2014 at 4:33 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: Yes, increasing the set of name-alikes between html and svg is absolutely not something we'll support. (I've unfortunately been out of the loop with the svgwg for a while, or else I would have prevented this from showing up in the first place.) Allowing html directly in svg is definitely the right answer. Parsing shouldn't be too hard, and defining the layout model would be pretty trivial. I think we should actually figure this out. I'm not an expert on the HTML parser, but it seems to me there's already some support for what we need. E.g. given !DOCTYPE HTML svg span id=s/span div id=i/div the elements s and i are put in the HTML namespace already. For layout, we could do this: 1) When an HTML element is a child of an SVG element, perform CSS layout of the HTML element treating the nearest SVG viewport as the containing block. Its user-space width and height become the width and height of the containing block in CSS pixels. 2) Treat such HTML elements as position:relative. 3) Add x and y attributes to HTMLElement and have them map to left and top CSS properties. (There's a crazy legacy compat issue for HTMLImageElement.x/y but we can hack around that.) We will have the x, y properties. No need to map to left and right. 4) Add a transform attribute to HTMLElement and have it map to the transform CSS property. In this case we should think about making transform a presentation attribute in general for HTML and SVG. #3 and #4 are optional, there are pros and cons to having them. Using the nearest SVG viewport in #1 is because other SVG container elements don't have a defined size (and we can't use getBBox because that depends on the layout of the children). Greetings, Dirk
[whatwg] Move contentEditable/isContentEditable from HTMLElement to Element?
Hi, contentEditable can be fairly useful in SVG as well. It partly works for inline SVG content in web browsers today. The question is, should SVGElement add support for contentEditable/isContentEditable and add it to its interface? Or should both attributes move to the Element interface instead? Greetings, Dirk
Re: [whatwg] Canvas normalize rect() and strokeRect()
On Apr 6, 2014, at 3:23 AM, Rik Cabanier caban...@gmail.com wrote: On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze dschu...@adobe.com wrote: Hi, I looked at the behavior of negative width or height for the rect() and strokeRect() functions. All browsers normalize the passed parameters for strokeRect() to have positive width and height. strokeRect(90,10,-80,80) — strokeRect(10,10,80,80) http://jsfiddle.net/za945/ It also seems that only firefox is following the spec [1] when width or height are 0: http://jsfiddle.net/za945/2/ I'm unsure why such a rectangle is defined as a straight line. You mean you would rather let it draw a one dimensional rectangle? So for the dimension that is not zero, you would see two overlapping lines + the 0 dimensional sides? That seems indeed to be the case for IE, Safari and Blink: http://jsfiddle.net/Gh9XK/ Just WebKit seems to normalize for rect() as well: http://jsfiddle.net/VT4MG/ The behavior of normalizing is not specified. Especially it seems odd that the behavior for fillRect()/strokeRect() should differ from rect(). So we should either normalize for all functions or don’t do it for all IMO. Note: fillRect() and clearRect() are not affected. The behavior for rect() is important for filling with different winding rules as well. It is not just stroking with dash arrays that is effected. yes, the spec needs to say in that order as it does for fillRect and strokeRect. Ok, that means you would be in favor not to normalize. Again, all current browser normalize and do NOT draw “in that order” for fillRect() and strokeRect(). That means you would require to give up the currently interoperable behavior. Greetings, Dirk 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrect
[whatwg] Canvas Computing text metrics
Hi, The spec says that the object TextMetrics[1] must return font and actual text metrics. All things require information from the font or the font system. In many cases either font or font system just do not provide these information. Instead of assuming that all information are accessible by the browser, it might be useful to define some heuristics that can be used. In WebKit and Blink we support the CSS dominant-baseline property in SVG that requires similar metrics as well[2]. Even SVG does not specify the heuristics yet and instead leaves that up to the browser. WebKit and Blink use the heuristics described in the documentation from Apache FOP[1]. Should these be used as fallback heuristics? Note: Many browsers might use heuristics by default since they can’t get all necessary font metrics at all. Greetings, Dirk [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#textmetrics [2] http://www.w3.org/TR/SVG11/text.html#TextAlignmentProperties [3] http://wiki.apache.org/xmlgraphics-fop/LineLayout/AlignmentHandling
Re: [whatwg] Canvas normalize rect() and strokeRect()
On Apr 6, 2014, at 8:24 AM, Rik Cabanier caban...@gmail.com wrote: On Sat, Apr 5, 2014 at 11:00 PM, Dirk Schulze dschu...@adobe.com wrote: On Apr 6, 2014, at 3:23 AM, Rik Cabanier caban...@gmail.com wrote: On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze dschu...@adobe.com wrote: Hi, I looked at the behavior of negative width or height for the rect() and strokeRect() functions. All browsers normalize the passed parameters for strokeRect() to have positive width and height. strokeRect(90,10,-80,80) — strokeRect(10,10,80,80) http://jsfiddle.net/za945/ It also seems that only firefox is following the spec [1] when width or height are 0: http://jsfiddle.net/za945/2/ I'm unsure why such a rectangle is defined as a straight line. You mean you would rather let it draw a one dimensional rectangle? So for the dimension that is not zero, you would see two overlapping lines + the 0 dimensional sides? yes That seems indeed to be the case for IE, Safari and Blink: http://jsfiddle.net/Gh9XK/ Just WebKit seems to normalize for rect() as well: http://jsfiddle.net/VT4MG/ The behavior of normalizing is not specified. Especially it seems odd that the behavior for fillRect()/strokeRect() should differ from rect(). So we should either normalize for all functions or don’t do it for all IMO. Note: fillRect() and clearRect() are not affected. The behavior for rect() is important for filling with different winding rules as well. It is not just stroking with dash arrays that is effected. yes, the spec needs to say in that order as it does for fillRect and strokeRect. Ok, that means you would be in favor not to normalize. Again, all current browser normalize and do NOT draw “in that order” for fillRect() and strokeRect(). That means you would require to give up the currently interoperable behavior. I changed your test a bit so you can more easily see the normalisation: http://jsfiddle.net/za945/3/ Safari and Chrome are doing as you say, but Firefox does not. (I don't have IE to test) Firefox has a strange different behavior if dash = gap. If the gap is smaller it behaves like IE, Blink and WebKit. This also answers your question: Your example renders in IE the same as in WebKit and Blink. Greetings, Dirk I would be in favor to change the blink/webkit behavior as the specified one makes more sense.
[whatwg] Canvas normalize rect() and strokeRect()
Hi, I looked at the behavior of negative width or height for the rect() and strokeRect() functions. All browsers normalize the passed parameters for strokeRect() to have positive width and height. strokeRect(90,10,-80,80) — strokeRect(10,10,80,80) http://jsfiddle.net/za945/ Just WebKit seems to normalize for rect() as well: http://jsfiddle.net/VT4MG/ The behavior of normalizing is not specified. Especially it seems odd that the behavior for fillRect()/strokeRect() should differ from rect(). So we should either normalize for all functions or don’t do it for all IMO. Note: fillRect() and clearRect() are not affected. The behavior for rect() is important for filling with different winding rules as well. It is not just stroking with dash arrays that is effected. Greetings, Dirk
Re: [whatwg] Canvas textBaseline 'middle' conflicting definition
On Mar 31, 2014, at 5:06 PM, Justin Novosad ju...@google.com wrote: Wow, that is confusing. How can this be fixed without breaking existing web content? Are browsers currently compliant with the canvas spec, or do they implement the CSS definition of middle? WebKit uses the definition for Canvas. It looks like David Hyatt implemented it in WebKit for Canvas following the Canvas spec a couple of years ago. Therefore, I assume it is the same for Blink. Didn’t check Gecko. WebKit and Blink both implement 'alignment-baseline' following the definition in SVG as well. Very unfortunate the confusion. Greetings, Dirk On Sun, Mar 30, 2014 at 3:11 PM, Dirk Schulze dschu...@adobe.com wrote: Hi, Canvas let you set alignment baselines with the textBaseline attribute [1]. One of the baseline values is ‘middle’. The description of the ‘middle’ baseline seems to be in conflict with the definition for the alignment-baseline property in CSS[2]. Canvas: The middle of the em square CSS: [..] it may be computed using 1/2 the x-height” What Canvas uses as middle is described as ‘center’ in CSS. Is there a way that we can change the naming and/or definition of ‘middle’ in Canvas? Greetings, Dirk [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-textbaseline [2] http://www.w3.org/TR/SVG11/text.html#TextAlignmentProperties
[whatwg] Canvas textBaseline 'middle' conflicting definition
Hi, Canvas let you set alignment baselines with the textBaseline attribute [1]. One of the baseline values is ‘middle’. The description of the ‘middle’ baseline seems to be in conflict with the definition for the alignment-baseline property in CSS[2]. Canvas: The middle of the em square CSS: [..] it may be computed using 1/2 the x-height” What Canvas uses as middle is described as ‘center’ in CSS. Is there a way that we can change the naming and/or definition of ‘middle’ in Canvas? Greetings, Dirk [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-textbaseline [2] http://www.w3.org/TR/SVG11/text.html#TextAlignmentProperties
Re: [whatwg] Singular CTM and currentTransform
On Mar 26, 2014, at 1:07 PM, Hwang, Dongseong dongseong.hw...@intel.com wrote: Maklng path primitives and draw calls no-ops when the CTM is non-invertible is simple to spec, implement, test, and understand for developers. I strongly agree on Justin. I agree as well. I would suggest that the getter either: 1) throws and invalid state error if the CTM is not invertible 2) returns 0. In WebIDLit would look like: SVGMatrix? getTransform(); afaik, we generally avoid throwing exception. am I right? Canvas throws a lot actually but I am open for option 2 as well. Greetings, Dirk Br, DS
[whatwg] Singular CTM and currentTransform
Hi, Independent if getter getTransform/getCTM or attribute currentTransform, what should be returned for a CTM that is singular (not invertible)? In WebKit we do not track all transformations of the CTM that caused a singular matrix or are following a transformation that would have caused a singular matrix. Example: ctx.scale(0,0); ct.translate(10,10); In webkit we would not apply the transformation scale(0,0) and mark the CTM as not-invertible instead. So we could not return an SVGMatrix object with a = b = c = d = 0; e = f = 10 because we actually don’t know the CTM after applying all transforms. I would suggest that the getter either: 1) throws and invalid state error if the CTM is not invertible 2) returns 0. In WebIDLit would look like: SVGMatrix? getTransform(); Greetings, Dirk PS: This is one reason I prefer a getter over an attribute because the getter does not return a mutable (live) SVGMatrix. But even than the problem above is not fully solved of course.
Re: [whatwg] Singular CTM and currentTransform
On Mar 25, 2014, at 8:46 PM, Rik Cabanier caban...@gmail.com wrote: On Tue, Mar 25, 2014 at 12:35 PM, Justin Novosad ju...@google.com wrote: On Tue, Mar 25, 2014 at 3:15 PM, Rik Cabanier caban...@gmail.com wrote: I agree. That issue has the same root problem as currentTransform. It would be nice to get closure. Justin, you hinted that you would be willing to follow the spec which would make you match Firefox and IE. Are still planning on doing that? I'm in a holding pattern. I prepared a code change to that effect, but then there was talk of changing the spec to skip path primitives when the CTM is not invertible, which I think is a good idea. It would avoid a lot of needless hoop jumping on the implementation side for supporting weird edge cases that have little practical usefulness. Right now, there is no browser interoperability when using non-invertible CTMs, and the web has been in this inconsistent state for a long time. The fact that this issue has never escalated (AFAIK) is a strong hint that no one out there really cares about this use case, so we should probably just go for simplicity. Maklng path primitives and draw calls no-ops when the CTM is non-invertible is simple to spec, implement, test, and understand for developers. Great to hear! I volunteer to update the Firefox implementation if we can get consensus. (see https://bugzilla.mozilla.org/show_bug.cgi?id=931587) Speaking for WebKit, support for changing the spec from me as well. Doing it according to the spec would be difficult, if possible at all in WebKit. Greetings, Dirk Note that Firefox is still non-compliant if there's a non-invertible matrix during filling/stroking/clipping PS: This is one reason I prefer a getter over an attribute because the getter does not return a mutable (live) SVGMatrix. But even than the problem above is not fully solved of course.
Re: [whatwg] Proposal: change 2D canvas currentTransform to getter method
On Mar 24, 2014, at 4:43 PM, Rik Cabanier caban...@gmail.com wrote: On Mon, Mar 24, 2014 at 8:34 AM, Simon Sarris simon.sar...@gmail.com wrote: On Mon, Mar 24, 2014 at 11:26 AM, Hwang, Dongseong dongseong.hw...@intel.com wrote: Looking over this thread, we make a consensus not to expose currentTransform attribute. Now, all we have to decide is API Option 1, SVGMatrix getTransform(); void setTransform(SVGMatrix); -- it overrides void setTransform(unrestricted double a, unrestricted double b, unrestricted double c, unrestricted double d, unrestricted double e, unrestricted double f); Option 2, SVGMatrix getCTM(); void setCTM(SVGMatrix); Option 3, SVGMatrix getCurrentTransform(); void setCurrentTransform(SVGMatrix); Which is the best? Greetings, DS I'm heavily in favor of option 1. I think using Current in the naming convention is silly. The transform just as much a part of state as lineWidth/etc, but nobody would propose naming lineWidth something like currentLineWidth! There's no way to get a *non-current* transformation matrix (or lineWidth), so I think the distinction is unnecessary. CTM only seems like a good idea if we're worried that the name is too long, but since Current is redundant/extraneous, I don't think an initialism is worth the added layer of confusion. I suggested getCTM() because it is already exposed to the Web stack. Adding yet another function with the same behavior and return value but different name has not much value IMO. Btw. there is a difference of the current transformation matrix and a normal transformation matrix. CTM is much more explicit in general and therefore used in specifications. +1 There's already a transform function that takes an array that works the same way. transform is different and appends a matrix to the CTM, it is not a CTM nor does it set the CTM. That is why you can not compare it. setTransform is different which takes 6 doubles and actually sets the CTM. Also, there is no equivalent for a setter in SVG. That is why I do not care much about the name of the setter. Greetings, Dirk
[whatwg] ImageData constructor questions
Hi, I was reading the spec part about ImageData [1]. 1) I noticed that createImageData() is explicit that it represent a transparent black rectangle. The constructor for ImageData is not that explicit. 2) The last step of the 2nd constructor that takes an Uint8ClampedArray says: • Return a new ImageData object whose width is sw, whose height is height, and whose data is source.” Is data a reference to the original source or a copy of source? For the former, there might be two ImageData objects referencing the same ByteArray. How would that be useful? Greetings, Dirk [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dfnReturnLink-7 (4.12.4.2.16 Pixel manipulation)
Re: [whatwg] Proposal: change 2D canvas currentTransform to getter method
Sent from my iPhone On Mar 22, 2014, at 5:11 AM, Rik Cabanier caban...@gmail.com wrote: On Thu, Mar 20, 2014 at 11:18 AM, Simon Sarris simon.sar...@gmail.comwrote: On Thu, Mar 20, 2014 at 1:52 PM, Justin Novosad ju...@google.com wrote: Hello all, The recently added currentTransform attribute on CanvasRenderingContext2D gives shared access to the rendering context's transform. By shared, I mean: a) this code modifies the CTM: var matrix = context.currentTransform; matrix.a = 2; b) In this code, the second line modifies matrix: var matrix = context.currentTransform; context.scale(2, 2); This behavior is probably not what most developers would expect. I would like to propose changing this to a getter method instead. We already have a setter method (setTransform). In another thread entitled Canvas Path.addPath SVGMatrix not optimal, Dirk Schulze proposed using the name getCTM, which would be consistent with the SVGLocatable interface, where getCTM returns an SVGMatrix. On the other hand, we could call it getTransform to be consistent with the existing setTransform on CRC2D. Opinions? Perhaps we should also have an overload of setTransform (or setCTM) that would take an SVGMatrix. First of all, have any browsers shipped currentTransform yet? Thoughts? -Justin Novosad FF (at least Aurora/Nightlies) has for some time had mozCurrentTransform (and mozCurrentTransformInverse), which return an Array (so not spec-compliant, since spec wants SVGMatrix). It is not shared, so it does not do what your a) and b) examples do. I agree that changing it to a getter method would be better, it would be more intuitive and clear for developers. Looking over this thread, getTransform gets the most support. we could add the following methods: SVGMatrix getTransform(); void setTransform(SVGMatrix); The getter does. I would still vote for interoperability and name it getCTM() which returns an SVGMatrix in SVG too. Greetings Dirk
Re: [whatwg] Canvas Path.addPath SVGMatrix not optimal?
So can we agree on:
addPath(Path, optional SVGMatrix)
(Independent of the discussion about CanvasPathMethods.)
Does some one think it would be necessary to make SVGMatrix nullable (optional
SVGMatrix?)? I think it would be superfluous.
Greetings,
Dirk
On Mar 21, 2014, at 8:02 PM, Joe Gregorio
jcgrego...@google.commailto:jcgrego...@google.com wrote:
On Wed, Mar 19, 2014 at 4:46 PM, Dirk Schulze
dschu...@adobe.commailto:dschu...@adobe.com wrote:
Hi,
I just looked at the definition of Path.addPath[1]:
void addPath(Path path, SVGMatrix? transformation);
SVGMatrix is nullable but can not be omitted all together. Why isn't it
optional as well? I think it should be optional, especially because creating an
SVGMatrix at the moment means writing:
var matrix =
document.createElementNS('http://www.w3.org/2000/svg','svg').createSVGMatrix();
Agreed, that's painful, +1 for making it optional.
-joe
Greetings,
Dirk
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#path
Re: [whatwg] addPath and CanvasPathMethods
On Mar 20, 2014, at 6:31 PM, Rik Cabanier caban...@gmail.com wrote: addPath is currently defined on the Path2D object. [1] Is there a reason why it's not defined on CanvasPathMethods instead? That way this method is available on the 2d contest so you can append a path to the current graphics state. This would also negate the need for setCurrentPath. I am supportive for this idea! I agree that this would solve one of the reasons why I came up with currentPath for WebKit in the first place. Greetings, Dirk 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-path-addpath
Re: [whatwg] addPath and CanvasPathMethods
On Mar 20, 2014, at 7:44 PM, Justin Novosad ju...@google.com wrote: This would apply the CTM to the incoming path, correct? I am a little bit concerned that this API could end up being used in ways that would cancel some of the performance benefits (internal caching opportunities) of Path2D objects. Where is the difference to fill(Path2D), stroke(Path2D) and clip(Path2D)? The path will always need to be transformed to the CTM. Graphic libraries usually do this already for you. The addPath() proposal is not different to that. Greetings, Dirk On Thu, Mar 20, 2014 at 1:49 PM, Dirk Schulze dschu...@adobe.com wrote: On Mar 20, 2014, at 6:31 PM, Rik Cabanier caban...@gmail.com wrote: addPath is currently defined on the Path2D object. [1] Is there a reason why it's not defined on CanvasPathMethods instead? That way this method is available on the 2d contest so you can append a path to the current graphics state. This would also negate the need for setCurrentPath. I am supportive for this idea! I agree that this would solve one of the reasons why I came up with currentPath for WebKit in the first place. Greetings, Dirk 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-path-addpath
[whatwg] Canvas Path.addPath SVGMatrix not optimal?
Hi,
I just looked at the definition of Path.addPath[1]:
void addPath(Path path, SVGMatrix? transformation);
SVGMatrix is nullable but can not be omitted all together. Why isn’t it
optional as well? I think it should be optional, especially because creating an
SVGMatrix at the moment means writing:
var matrix =
document.createElementNS('http://www.w3.org/2000/svg','svg').createSVGMatrix();
Greetings,
Dirk
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#path
[whatwg] Canvas Path.addPath SVGMatrix not optimal?
Hi,
I just looked at the definition of Path.addPath[1]:
void addPath(Path path, SVGMatrix? transformation);
SVGMatrix is nullable but can not be omitted all together. Why isn’t it
optional as well? I think it should be optional, especially because creating an
SVGMatrix at the moment means writing:
var matrix =
document.createElementNS('http://www.w3.org/2000/svg','svg').createSVGMatrix();
I would even argue that SVGMatrix should just be optional.
Greetings,
Dirk
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#path
Re: [whatwg] Canvas Path.addPath SVGMatrix not optimal?
On Mar 19, 2014, at 10:48 PM, Rik Cabanier
caban...@gmail.commailto:caban...@gmail.com wrote:
On Wed, Mar 19, 2014 at 2:22 PM, Justin Novosad
ju...@google.commailto:ju...@google.com wrote:
On Wed, Mar 19, 2014 at 4:46 PM, Dirk Schulze
dschu...@adobe.commailto:dschu...@adobe.com wrote:
Hi,
I just looked at the definition of Path.addPath[1]:
void addPath(Path path, SVGMatrix? transformation);
SVGMatrix is nullable but can not be omitted all together. Why isn't it
optional as well? I think it should be optional, especially because
creating an SVGMatrix at the moment means writing:
var matrix = document.createElementNS('http://www.w3.org/2000/svg
','svg').createSVGMatrix();
Greetings,
Dirk
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#path
I agree it should be optional, but just to play devil's advocate : you can
create an identity SVGMatrix with a simpler bit of code. Just do this right
after creating a canvas rendering context: var identity =
context.currentTransform;
Hi Justin,
did Blink already expose this property?
As currently specified, this must return a live SVGMatrix object, meaning that
as you change the CTM on the 2d context, your reference to the SVGMatrix should
change as well. [1]
It's unlikely that you actually want this...
This API should be renamed to get/setCurrentTransform() and return a copy.
It could be called getCTM() which SVG offers on SVGElements and also returns an
SVGMatrix object. But I agree that it would be easier if we return a copy
instead of a live object.
What does Blink do?
Greetings,
Dirk
1:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-currenttransform
Re: [whatwg] Questions regarding Path object
On Mar 18, 2014, at 10:38 AM, Jürg Lehni li...@scratchdisk.com wrote:
So is currentPath going away then for sure? Will there still be a way to to
retrieve a Path2D representation of the path being drawn by the long existing
drawing commands on the context?
I quite liked how I could use it for caching, in case the browser supported
that feature, and check wether I have a cached path the next time I need to
draw it, falling back on redrawing it using the same drawing commands. Doing
the same by feature-detecting the Path(2D) constructor and building separate
drawing approaches based on its existence results in much more complicated
code.
I am still in favor for a setter and getter as well. It had the benefit that
you were able to transform the context and it affected drawing commands as
well. It is more complicated to create a second Path2D object and add it to a
previous path with a transform.
I have to admit that the currentPath attribute implemented in WebKit was a
mistake though. It created copies instead of references. It seems that Blink
and Firefox are more willing to follow the current spec. Therefore, I added
Path2D as argument for fill, stroke and clip in WebKit. currentPath was removed
and Path renamed to Path2D.
Greetings,
Dirk
J
On Mar 14, 2014, at 23:18 , Rik Cabanier caban...@gmail.com wrote:
On Wed, Dec 4, 2013 at 5:18 PM, Rik Cabanier caban...@gmail.com wrote:
On Wed, Dec 4, 2013 at 11:10 AM, Jürg Lehni li...@scratchdisk.com wrote:
I somehow managed to oversee all the things that happened in this
discussion, but I'm very happy to see that Path2D is being proposed and
agreed on now. It's also what I've originally suggested on April 10 this
year, and I completely agree that it leaves much less doubt about its
functionality and context of use. It also has a history as a term in Java2D:
http://docs.oracle.com/javase/7/docs/api/java/awt/geom/Path2D.html
So is this going through?
Yes, all that need to happen is for someone to implement this :-)
Path2D has now landed in Blink [1]. Blink also implemented the 'addPath'
method.
WebKit just landed a patch to rename Path to Path2D, remove currentPath and
add fill/stroke/clip with a path [2].
A patch is under review for Firefox to add Path2D.
Given this, can we change the spec to reflect the new name?
1: https://codereview.chromium.org/178673002/
2: https://webkit.org/b/130236
3: https://bugzilla.mozilla.org/show_bug.cgi?id=830734
On Nov 18, 2013, at 19:03 , Elliott Sprehn espr...@gmail.com wrote:
On Monday, November 18, 2013, Rik Cabanier wrote:
On Wed, Nov 13, 2013 at 1:36 PM, Robert O'Callahan
rob...@ocallahan.orgjavascript:_e({}, 'cvml', 'rob...@ocallahan.org');
wrote:
On Wed, Nov 13, 2013 at 12:12 PM, Jussi Kalliokoski
jussi.kallioko...@gmail.com javascript:_e({}, 'cvml',
'jussi.kallioko...@gmail.com'); wrote:
Path is also too generic even in the context of graphics. If we later on
want to add a path object for 3-dimensional paths, you end up with Path
and
Path3D? Yay for consistency. Path2D would immediately inform what
dimensions we're dealing with and also that this is to do with graphics,
and thus sounds like a good name to me.
Sounds good to me.
Elliot,
what do you think, is Path2D acceptable?
Sounds great to me, lets do it!
- E
Re: [whatwg] [Canvas] Behavior on non-invertable CTM
On Mar 17, 2014, at 3:49 PM, Justin Novosad ju...@google.com wrote: On Fri, Mar 14, 2014 at 4:50 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 7 Feb 2014, Justin Novosad wrote: Current text: If the point (x0, y0) is equal to the point (x1, y1), or if the point (x1, y1) is equal to the point (x2, y2), or if both radiusX and radiusY are zero, then the method must add the point (x1, y1) to the subpath, and connect that point to the previous point (x0, y0) by a straight line. With arcTo, the first point (x0, y0) may have been added to the current subpath using a different CTM. So to bring it into the local space of the current primitive, we need an invertible CTM. What I don't understand is why you can't draw the curve in the transformed space instead of the 1:1 coordinate space. You have to transform it eventually, right? And the points will end up simply transformed. So you can easily compare the points in the transformed space. All the transforms are affine, so what's a straight line isn't impacted. Can't you just draw the transformed arc instead of first drawing the circular arc and then transforming it? Maybe what I'm saying is obviously dumb for some reason, but I'm not understanding why, if so... (not that I'm a graphics guy, obviously. Hmmm, I gave this a bit more thought... To apply the construction algorithm in transformed space, the ellipse parameters (radiusX, radiusY, rotation) would have to be transformed. Transforming the parameters would be intractable under a projective transform (e.g. perspective), but since we are limitted to affine transforms, it can be done. Now, in the case of a non-invertible CTM, we would end up with radiusX or radiusY or both equal to zero. And what happens when you have that? Your arcTo just turned into lineTo(x1, y1). Tada! Why does radiusX or radiusY need to be zero? Because you define it that way for a non-invertible matrix? That makes sense for scale(0,0). What about infinity or NaN? If Ian didn’t update the spec then this is still undefined and therefore up to the UA to decide. Greetings, Dirk -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [Canvas] Behavior on non-invertable CTM
On Mar 17, 2014, at 9:23 PM, Justin Novosad ju...@google.com wrote:
On Mon, Mar 17, 2014 at 2:06 PM, Rik Cabanier caban...@gmail.com wrote:
Make a clean cut and define that drawing operators are ignored when there's a
non-invertible matrix.
I could totally go for that, but you are talking about going back on the spec
of a feature that has shipped, as opposed to clarifying edges cases. Maybe
that would be fine in this case though...
I'm unsure if anyone has shipped that part of the spec. There's certainly no
interop...
Plenty of browser have shipped drawing paths to canvas. I agree about the no
interop part. It is the main reason I think it may still be acceptable to
redefine the spec.
Looking at the implementation in Blink and WebKit, all of the drawing methods
and fill/stroke/clip start with:
if (!isTransformInvertible())
return;
At first glance, Firefox seems to do what the spec says (which results in
slow double transforming of all coordinates) but then they punt as well:
Matrix inverse = mTarget-GetTransform();
if (!inverse.Invert()) {
NS_WARNING(Could not invert transform);
return;
}
So, what we could say is:
- when drawing paths, ignore all calls if the matrix is non-invertible
(WebKit and Blink do this)
- when filling/stroking/clipping, ignore all calls if the matrix is
non-invertible (Firefox, WebKit and Blink do this)
Yes, but there is still an issue that causes problems in Blink/WebKit:
because the canvas rendering context stores its path in local (untransformed)
space, whenever the CTM changes, the path needs to be transformed to follow
the new local spcae. This transform requires the CTM to be invertible. So
now webkit and blink have a bug that causes all previously recorded parts of
the current path to be discarded when the CTM becomes non-invertible (even if
it is only temporarily non-invertible, even if the current path is not even
touched while the matrix is non-invertible). I have a fix in flight that
fixes that problem in Blink by storing the current path in transformed
coordinates instead. I've had the fix on the back burner pending the outcome
of this thread.
Are you sure about this? The path should stay untouched during the time the CTM
is not invertible. At least in WebKit I can not remember that I see the path
discarded. As Rik quoted in the code snippet, we just return silently and do
not touch the path and avoid daring operations.
Greetings,
Dirk
[whatwg] Support filters in Canvas
Hi,
Apologize if it was already discussed but I couldn’t find a mail to this topic.
In one of the early drafts of Filter Effects we had filter operation support
for HTML Canvas. We deferred it and IMO it makes more sense to have it as part
of the Canvas specification text.
I would suggest a filter attribute that takes a list of filter operations
similar to the CSS Image filter function[1]. Similar to shadows[2], each
drawing operation would be filtered. The API looks like this:
partial interface CanvasRenderingContext2D {
attribute DOMString filter;
}
A filter DOMString could looks like: “contrast(50%) blur(3px)”
With the combination of grouping in canvas[3] it would be possible to group
drawing operations and filter them together.
Filter functions include a reference to a filter element and a specification
of SVG filters[4]. I am unsure if a reference do an element within a document
can cause problems. If it does, we would just not support SVG filter references.
Greetings,
Dirk
[1] http://dev.w3.org/fxtf/filters/#interpolating-filter-image
[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#shadows
[3] http://lists.w3.org/Archives/Public/public-canvas-api/2013AprJun/0009.html
[4] http://dev.w3.org/fxtf/filters/#FilterElement
Re: [whatwg] hit regions: clearing of regions
On Mar 12, 2014, at 12:13 AM, Rik Cabanier caban...@gmail.com wrote: On Tue, Mar 11, 2014 at 10:03 AM, Edward O'Connor eocon...@apple.comwrote: Hi Rik, You wrote: Currently, the specification states that if you create a region and then create another region that completely covers region, the first region is removed from the hit region list [1] This is a complex operation that involves either drawing the regions to a bitmaps and counting pixels, or path intersection. It is also unintuitive because an author might expect that he could remove the second region and still have the first region active. What was the reason that this was added to the spec? The model the spec uses for hit regions is that you have two bitmaps--one for the canvas surface, and the other is used to track which hit region the pixels of the canvas surface are in. See this thread from 2012: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-July/thread.html#36556 Thanks! It looks like that thread never came to a conclusion. The arguments against using a bitmap presentation still stand: - it will be too expensive to keep an actual copy of the canvas pixels in memory to do hit testing - if you have to mimic the behavior with paths, you need access to expensive/difficult path manipulation algorithms Hit regions should be redesigned so they work on the path geometry as opposed to pixels. We already have the necessary code to do hit testing on paths (see isPointInPath) In SVG we tried to avoid having hit testing based on pixel values obviously for performance reasons. Greetings, Dirk
Re: [whatwg] new constructor method for Path2D
On Mar 10, 2014, at 7:02 PM, Rik Cabanier caban...@gmail.com wrote: On Sun, Mar 9, 2014 at 10:52 PM, Dirk Schulze dschu...@adobe.com wrote: On Mar 10, 2014, at 3:44 AM, Rik Cabanier caban...@gmail.com wrote: On Wed, Mar 5, 2014 at 1:46 PM, Rik Cabanier caban...@gmail.com wrote: While implementing the Path2D object in mozilla, we ran into a performance issue. The mozilla implementation uses different backends for the canvas 2D context. Even within the same document, different canvas objects can be on top of different graphics libraries. For best performance, the Path2D object should use the same graphics interface as the canvas context you're applying it to. If this is not the case, the path segments have to be walked and converted which is a costly operation. To work around this, we could add a couple of constructor methods to the 2D context: Path2D createPath(); Creates a new empty Path object. Path2D createPath(path); Creates a new Path object that is a copy of the argument. Path2D createPath(d); Creates a new path with the path described by the argument, interpreted as SVG path data. [SVG] This way, we can guarantee that they use the same underlying technology and performance won't be impacted. You could still pass these objects to other canvas contexts but performance might be impacted. I was thinking about this a bit more and an alternate solution would be to pass an optional 2D context to the Path2D constructors. A UA could ignore that context, or it could see it as a hint that the path is going to be used with that context. Thoughts? Slightly better. Still not sure. What are you not sure about? The current Path2D interface might be unacceptably slow under certain circumstances and there's currently no way for authors to work around this. There has to be a hint. If not, I don't see a way that firefox will ship this. Since no other implementation stood up so far it seems to be a FF only hack at the moment. The question is how common s it to have multiple contexts of different type within the same document? How often does it happen that you use the same Path2d object in multiple contexts? We need data for that first. Even switching the context during run-time (as you suggested is happening in Firefox) would not help in your proposal. You would still encode and decode the path again. Actually, with the right abstraction it is just the creation of the path object which shouldn’t be very slow at all. Especially since you create it once and reuse it over and over again. Having an optional value for the constructor is not as bad as binding the Path2d creation to a specific context. I still don’t see the need to do this at the moment. Beside that, the optional argument can be done later if it really turns out to be a problem that can not worked around in any other way. Therefore, I would like to see efforts in Gecko to speed the specified version up first and revisit the proposal later. Greetings, Dirk
Re: [whatwg] new constructor method for Path2D
On Mar 10, 2014, at 3:44 AM, Rik Cabanier caban...@gmail.com wrote: On Wed, Mar 5, 2014 at 1:46 PM, Rik Cabanier caban...@gmail.com wrote: While implementing the Path2D object in mozilla, we ran into a performance issue. The mozilla implementation uses different backends for the canvas 2D context. Even within the same document, different canvas objects can be on top of different graphics libraries. For best performance, the Path2D object should use the same graphics interface as the canvas context you're applying it to. If this is not the case, the path segments have to be walked and converted which is a costly operation. To work around this, we could add a couple of constructor methods to the 2D context: Path2D createPath(); Creates a new empty Path object. Path2D createPath(path); Creates a new Path object that is a copy of the argument. Path2D createPath(d); Creates a new path with the path described by the argument, interpreted as SVG path data. [SVG] This way, we can guarantee that they use the same underlying technology and performance won't be impacted. You could still pass these objects to other canvas contexts but performance might be impacted. I was thinking about this a bit more and an alternate solution would be to pass an optional 2D context to the Path2D constructors. A UA could ignore that context, or it could see it as a hint that the path is going to be used with that context. Thoughts? Slightly better. Still not sure. Dirk
Re: [whatwg] new constructor method for Path2D
On Mar 5, 2014, at 11:54 PM, Rik Cabanier caban...@gmail.com wrote: On Wed, Mar 5, 2014 at 2:43 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 5 Mar 2014, Jeff Muizelaar wrote: On Mar 5, 2014, at 5:34 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 5 Mar 2014, Rik Cabanier wrote: To work around this, we could add a couple of constructor methods to the 2D context: Path2D createPath(); Creates a new empty Path object [...] This used to be how many Web APIs worked, but over the years we've received enormous volumes of feedback to the effect that constructor-based APIs are way better than factory-based APIs. Is there no way we could at least have all the canvases within a Document in Firefox use the same backend? It would be really unfortunate to have to use factories here to get around an implementation detail in one browser. The choice of backend depends on the size of the canvas. So it wouldn't be easy to have all canvases within a document use the same backend. Ah, ok. This makes a factory method somewhat less useful, because what if the canvas changes size later? Do all the paths have to be re-bound? for optimal performance, yes. Rescaling a canvas is not that common of a scenario though. To switch the context of a created Path2d, you still need an abstraction of the path, don’t you? Some platforms are not able to return the created path. Many more are not able to return an unflattened path (which might not be an issue). So if you might need an abstraction anyway, is the performance problem that you need to do it on each drawing operation? There are clearly ways to work around such an issue. Maybe this hint would be useful for Chrome since they switch to software under certain circumstances too I am unsure if it would. It is the same graphic library that manages the path object. Even if uses a different backend. Greetings, Dirk
Re: [whatwg] Document.title for SVG documents
On Feb 3, 2014, at 5:02 PM, Cameron McCormack c...@mcc.id.au wrote: Jonas Sicking wrote: An even simpler solution would be to say we choose the first html:title orsvg:title in document order. That has the nice property that we align SVG and HTML more. Although as Dirk pointed out, SVG distinguishes title elements that are children of the root element vs children of other elements. The title that is a child of the root element gives the title of the entire element, while a title child of another element in the document describes only that element (like title= does in HTML). You should compare screenreader output on IE and Firefox for Windows. SVG does differ titles in terms of hierarchy. The first title/desc element in the first hierarchy level after svg root is taken as title/description of the “document”. Document in the meaning that the outermost SVG root creates an SVG document. Any hierarchy after the first is the title/description of the group. Here two examples with inline description: svg titleThis is the title of the document/title /svg svg g titleThis is the title of the whole group with all decadents. Descendants can have there own title as well as a more detailed description of a sub tree. The SVG document has no title./title /g /svg The svg element within HTML content is by default used as image in most browsers. The role of the SVG document can be changed though. For some more information see blog post “Using ARIA to enhance SVG accessibility” which tests the accessibility in browsers. [1] I think we should not change the way accessibility is handled in SVG for the last 1.5 decades. ARIA on the other hand should behave the same as for HTML content (which it basically does). I am not aware of tests or researches that take different languages into account though. Anyway, I do not see how it would hurt if SVG defines accessibility for SVG content. We have some accessibility experts in the WG who add valuable input to the topic already. Greetings, Dirk [1] http://blog.paciellogroup.com/2013/12/using-aria-enhance-svg-accessibility/
Re: [whatwg] Document.title for SVG documents
On Feb 1, 2014, at 9:03 PM, Cameron McCormack c...@mcc.id.au wrote: Currently, HTML defines Document.title on SVG documents to defer to whatever the SVG specification defines for SVGDocument.title. The SVGDocument interface has gone away, so this will need to be updated. From some basic testing, it looks like SVG needs the same behaviour as HTML -- first title element in the document, plus the white space collapsing behaviour. Could you be more specific about that? It is not just the first title element in the document, but the first direct child of the element root. A title nested in a group or graphical element has a different meaning and shall not be used as title. If there is a nested title element but no direct title child of the SVG root, then the document has no title. This distinction is important for accessibility. Do you want to just handle that all in HTML? I'm not sure there's much value to duplicating either the searching for the title element or the white space collapsing behaviour in SVG itself.
Re: [whatwg] Fetch SVG images with No CORS tainted cross-origin
The document “SVG Integration Module Level 1” [1] is going to define the specifics of fetching in SVG. I hope to find the time to add actual content in January and would be happy for reviews after that. Greetings, Dirk [1] https://dvcs.w3.org/hg/svg2/raw-file/7a902f4a33f6/specs/integration/Overview.html On Nov 27, 2013, at 5:39 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/27/13 9:08 AM, Anne van Kesteren wrote: It seems weird to say Gecko has serious security concerns. Either there's a factual security issue or not, right? In theory, yes. In practice, opinions seem to differ, not least because one person's security/privacy issue is another's business model. In this particular case, last I checked, other UAs are more permissive than Gecko, and seem to not care about the issue we care about in this situation. And as far as I can tell the issue is that if someone allows uploading SVG images, people could include tracker images in those SVG images. That's correct. And therefore the SVG specification should simply outlaw that. I'm all for that, obviously. ;) Note that even then those SVG images cannot be hosted same-origin unless you run them through some kind of whitelist-based filter. Indeed. -Boris
Re: [whatwg] Questions regarding Path object
On Nov 13, 2013, at 2:53 PM, Rik Cabanier caban...@gmail.com wrote: [resending because of a bounced message] DrawingPath is saying the same thing twice. Maybe DOMDrawing is better? (with drawing the definition of http://dictionary.cambridge.org/dictionary/british/drawing?q=drawing) I disagree. http://dictionary.cambridge.org/dictionary/british/path_1?q=path 1) A Path is following a track. 2) Drawing is actually putting something visual on a surface. The former is true, the latter is not. Since the Path is not drawing anything but is just a simple representation of segments, the term “drawing” is misleading. Then it seems to be a verb, even though the segment representation isn’t doing anything. I know, I am not helping with that. Seriously, I do not believe that the first thing crossing the mind of randomly asked people on Path is file structure or URL. Greetings, Dirk On Tue, Nov 12, 2013 at 6:39 PM, Robert O'Callahan rob...@ocallahan.orgwrote: I bikeshed-+1 Elliott's earlier suggestion of DrawingPath. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w
Re: [whatwg] Questions regarding Path object
Sent from my iPhone On Nov 12, 2013, at 6:18 AM, Elliott Sprehn espr...@gmail.commailto:espr...@gmail.com wrote: On Mon, Nov 4, 2013 at 9:14 AM, Rik Cabanier caban...@gmail.commailto:caban...@gmail.com wrote: On Mon, Nov 4, 2013 at 2:07 AM, Jürg Lehni li...@scratchdisk.commailto:li...@scratchdisk.com wrote: Thinking more about this discussion, I had an idea for an approach that would avoid such future clashes all together: Instead of exposing constructors, why not simply expose the methods that create them? There already are such functions for gradients: ctx.createRadialGradient() ctx.createLinearGradient() Wouldn't it have been more aligned with this existing API also to have a ctx.createPath() ? The SVG WG would like to start using the 'Path' object for its objects as well. We'd like this to be a generic object that can be used by other parts of the web platform. It would be strange to require a canvas context just to create pathh. I'd like to again say I don't think this thing should be called Path. Lots of other things have Paths, like maps, file systems, urls, why does the drawing one get to take the global namespace? Given that there's a bunch of new objects with Drawing as the prefix, I think we should name this DrawingPath like DrawingStyle and friends. No. Greetings, Dirk - E
Re: [whatwg] Questions regarding Path object
On Nov 12, 2013, at 7:19 AM, Elliott Sprehn espr...@chromium.org wrote: On Mon, Nov 11, 2013 at 2:52 PM, Dirk Schulze dschu...@adobe.com wrote: ... The SVG WG would like to start using the 'Path' object for its objects as well. We'd like this to be a generic object that can be used by other parts of the web platform. It would be strange to require a canvas context just to create pathh. I'd like to again say I don't think this thing should be called Path. Lots of other things have Paths, like maps, file systems, urls, why does the drawing one get to take the global namespace? Given that there's a bunch of new objects with Drawing as the prefix, I think we should name this DrawingPath like DrawingStyle and friends. No. Then I object to us shipping this in Chrome. Bleeding on the global scope with such a generic name ignoring all the other reasonable uses of the word Path is not good for the platform. It's not forward thinking, and it's confusing for developers. No one is stopping you from objecting to ship it in Blink. I personally do not see any reason to diverge the web platform just because “Path” is a term that is also be used within the string “FilePath” or “URLPath. It seems rather obscure to add such a relation, since it is widely excepted that a path is a geometry if it doesn’t have a prefix that indicates otherwise. The naming topic was discussed too many times already and we always came back to Path. Safari on iOS and Mavericks ships with Path as well now. So it is your decision to block progress on the web platform or just stick to the naming. Greetings, Dirk Why is your one use case more important than FilePath, URLPath and MapPath? Why do all the other APIs get prefixes and yours doesn't? - E
Re: [whatwg] CanvasRenderingContext2D with addPath, currentPath
Under the described circumstances, I agree that we should ha a getter and setter for Path on CanvasRenderingContext2D. Greetings, Dirk On Nov 5, 2013, at 4:29 AM, Rik Cabanier caban...@gmail.com wrote: On Mon, Nov 4, 2013 at 5:21 PM, Robert O'Callahan rob...@ocallahan.orgwrote: If you return a path in user-space, what do you get if you call getCurrentPath with a singular transform? ctx.moveTo(0,0); ctx.lineTo(1,1); ctx.scale(0,0); var p = ctx.getCurrentPath(); I mixed up my terms :-) getCurrentPath should return the path in device coordinates (not user). However, for your example, I'm unsure what the right solution is. The canvas specification is silent on what the behavior is for non-invertible matrices. I think setting scale(0,0) or another matrix operation that is not reversible, should remove drawing operations from the state because: - how would you stroke with such a matrix? - how do patterns operate? the same for gradient fills. - how would you pass this to the underlying graphics library? - certain operators such as 'arc' rely on doing the transform in reverse. I seem to remember that for SVG we decided that non-invertible matrices don't draw either.
Re: [whatwg] CanvasRenderingContext2D with addPath, currentPath
On Nov 5, 2013, at 5:22 AM, Rik Cabanier caban...@gmail.com wrote: On Mon, Nov 4, 2013 at 7:29 PM, Rik Cabanier caban...@gmail.com wrote: On Mon, Nov 4, 2013 at 5:21 PM, Robert O'Callahan rob...@ocallahan.orgwrote: If you return a path in user-space, what do you get if you call getCurrentPath with a singular transform? ctx.moveTo(0,0); ctx.lineTo(1,1); ctx.scale(0,0); var p = ctx.getCurrentPath(); I mixed up my terms :-) getCurrentPath should return the path in device coordinates (not user). However, for your example, I'm unsure what the right solution is. The canvas specification is silent on what the behavior is for non-invertible matrices. I think setting scale(0,0) or another matrix operation that is not reversible, should remove drawing operations from the state because: - how would you stroke with such a matrix? - how do patterns operate? the same for gradient fills. - how would you pass this to the underlying graphics library? - certain operators such as 'arc' rely on doing the transform in reverse. I seem to remember that for SVG we decided that non-invertible matrices don't draw either. After pondering this some more and looking at the different implementations, I propose the following: if the user sets a non-invertible matrix, the canvas context should be in a state that ignores all path drawing operations, stroke/fill calls and all other ctm operations (apart from setTransform). setCurrentPath is also ignored and getCurrentPath should return an empty path. If the ctm becomes invertible again (from a setTransform or a restore), drawing operations pick up again with the currentPoint that was active when the non-invertible matrix was set. This is not the behavior of current browsers as discussed in a different threat about non-invertible CTMs. Firefox seems to add new path segments to the coordinate origin. The behavior of WebKit is a bit different and depends how the matrix got not-invertable. I am supportive for clear rules at this point. Ian’s response so far was that it doesn’t need any further definition. That is why no implementation changed the behavior since then. I could be convinced that set/getCurrentPath should still work... so If I expand your example a bit: ctx.moveTo(0,0); ctx.lineTo(1,1); ctx.scale(0,0); var p = ctx.getCurrentPath(); // return empty path ctx.stroke(); // nothing happens ctx.setTransform(1,0,0,1,0,0); p = ctx.getCurrentPath(); // return path with moveto/lineto ctx.stroke(); // draw line This would match what WebKit and Blink are doing. Firefox gets in a bad state as soon as you set a non-invertible matrix but we could fix that ;-) Again, the behavior is different depending on how you got to the not-invertible CTM, which is obviously not great. I would be supportive of not adding any path segments unless the CTM is invertible. IE keeps drawing and even strokes when scale(0,0) is set. It would be nice to have interop… Yes! Greetings, Dirk
Re: [whatwg] CanvasRenderingContext2D with addPath, currentPath
On Nov 5, 2013, at 6:56 PM, Rik Cabanier
caban...@gmail.commailto:caban...@gmail.com wrote:
On Tue, Nov 5, 2013 at 4:29 AM, Dirk Schulze
dschu...@adobe.commailto:dschu...@adobe.com wrote:
On Nov 5, 2013, at 5:22 AM, Rik Cabanier
caban...@gmail.commailto:caban...@gmail.com wrote:
On Mon, Nov 4, 2013 at 7:29 PM, Rik Cabanier
caban...@gmail.commailto:caban...@gmail.com wrote:
On Mon, Nov 4, 2013 at 5:21 PM, Robert O'Callahan
rob...@ocallahan.orgmailto:rob...@ocallahan.orgwrote:
If you return a path in user-space, what do you get if you call
getCurrentPath with a singular transform?
ctx.moveTo(0,0);
ctx.lineTo(1,1);
ctx.scale(0,0);
var p = ctx.getCurrentPath();
I mixed up my terms :-)
getCurrentPath should return the path in device coordinates (not user).
However, for your example, I'm unsure what the right solution is. The
canvas specification is silent on what the behavior is for non-invertible
matrices.
I think setting scale(0,0) or another matrix operation that is not
reversible, should remove drawing operations from the state because:
- how would you stroke with such a matrix?
- how do patterns operate? the same for gradient fills.
- how would you pass this to the underlying graphics library?
- certain operators such as 'arc' rely on doing the transform in reverse.
I seem to remember that for SVG we decided that non-invertible matrices
don't draw either.
After pondering this some more and looking at the different
implementations, I propose the following:
if the user sets a non-invertible matrix, the canvas context should be in a
state that ignores all path drawing operations, stroke/fill calls and all
other ctm operations (apart from setTransform). setCurrentPath is also
ignored and getCurrentPath should return an empty path.
If the ctm becomes invertible again (from a setTransform or a restore),
drawing operations pick up again with the currentPoint that was active when
the non-invertible matrix was set.
This is not the behavior of current browsers as discussed in a different threat
about non-invertible CTMs. Firefox seems to add new path segments to the
coordinate origin. The behavior of WebKit is a bit different and depends how
the matrix got not-invertable.
Yes, I was looking at the WebKit implementation since it looked the most
sensible.
I'm unsure why you say how the matrix got not-invertable. There are checks
all over the code to skip if the CTM is non-invertible, ie:
void CanvasPathMethods::moveTo(float x, float y){
...
if (!hasInvertibleTransform())
return;
I am supportive for clear rules at this point. Ian’s response so far was that
it doesn’t need any further definition. That is why no implementation changed
the behavior since then.
Is this the link:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org//2013-January/038798.html
I don't see any replies...
You had an error in one of your examples which probably why you thought there
was still drawing after scale(0,0), here are updated links:
http://jsfiddle.net/Dghuh/5/
http://jsfiddle.net/Dghuh/6/
I need to check the code again, it might be a mistake in the examples. I was
wondering about the mistake. Yes, WebKit has a lot of checks in the code to
avoid drawing (helped to add them :)).
Reply to my original post was on July 18 :) so you need to look a bit further
into the future :P
Greetings,
Dirk
I could be convinced that set/getCurrentPath should still work...
so If I expand your example a bit:
ctx.moveTo(0,0);
ctx.lineTo(1,1);
ctx.scale(0,0);
var p = ctx.getCurrentPath(); // return empty path
ctx.stroke(); // nothing happens
ctx.setTransform(1,0,0,1,0,0);
p = ctx.getCurrentPath(); // return path with moveto/lineto
ctx.stroke(); // draw line
This would match what WebKit and Blink are doing.
Firefox gets in a bad state as soon as you set a non-invertible matrix but
we could fix that ;-)
Again, the behavior is different depending on how you got to the not-invertible
CTM, which is obviously not great. I would be supportive of not adding any path
segments unless the CTM is invertible.
IE keeps drawing and even strokes when scale(0,0) is set.
It would be nice to have interop…
Yes!
Greetings,
Dirk
Re: [whatwg] CanvasRenderingContext2D with addPath, currentPath
On Nov 3, 2013, at 3:22 PM, Glenn Maynard gl...@zewt.org wrote: On Sat, Nov 2, 2013 at 9:03 PM, Rik Cabanier caban...@gmail.com wrote: Does this mean that ctx.currentPath != ctx.currentPath? Yes That's bad! Why would it be bad (apart from being different)? It's strange to say foo.bar.baz = 1 (ctx.currentPath.baz = 1), and for foo.bar.baz to not be 1 the next time you look. It's also confusing if you use it as a Map key. I think the problem that the UA would be focused with is the following: var path = ctx1.currentPath; ctx2.currentPath = path; or simply ctx2.currentPath = ctx1.currentPath Both contexts could manipulate the same path and both can have different CTMs which also change independent of each other. Mixing that up could cause a huge mess. That is one of the reasons why WebKit creates copies. Greetings, Dirk
[whatwg] Fetch SVG images with No CORS tainted cross-origin
Hi, If I understand HTML img fetching and the fetch spec right. The default behavior on image fetching is No CORS with the mode tainted cross-origin. For the example: img src=image.svg and image.svg: svg image xlink:href=http://otherdomain.com/image.svg; /svg In this case the image.svg would be fetched with basic fetch and tainted cross-origin. But the image inside this image would also be loaded as basic fetch tainted cross origin. Right? For various reasons (as described in Mozilla bug 628747[1]). We do not want to have image load further _external_ resources. WebKit, Blink and Gecko allow dataURLs and Gecko allows blobs as resources. I couldn't find a specification for that in the Fetch specification. WebKit and Blink call that single security origin. If the SVG was fetched as an image resource, it is not allowed to fetch other resources with the described exception above. So, I wonder how that behavior could be described. Sadly it is not always the same behavior. If the SVG image is referenced by an object, embed or iframe, it does not count as image anymore but as a document and it can fetch resources again. For my use case of mask and filter the SVG WG resolved to have the same fetching mechanisms and restrictions as for SVG as images. To summarize. We have two kind of possibilities of fetching in SVG: SVG with single security origin: The SVG is not allowed to fetch any external resources. References in the same document and dataURLs, blobs are allowed. SVG as document: Allowed to fetch resources with No CORS - But: possibly CORS enabled depending on the referencing element (object, embed or iframe). Would it be possible to define it that way? If the former named elements, then use the fetching mechanism defined by these elements. Otherwise use single security origin? Could Fetch define single security origin? Greetings, Dirk [1] https://bugzilla.mozilla.org/show_bug.cgi?id=628747
Re: [whatwg] Fetch SVG images with No CORS tainted cross-origin
On Sep 13, 2013, at 10:43 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Sep 13, 2013 at 9:27 AM, Dirk Schulze dschu...@adobe.com wrote: So, I wonder how that behavior could be described. I think you'd have a mode switch and maybe a wrapper for Fetch that only calls it for data and blob URLs. It seems like you don't really want to invoke Fetch at all for SVG as image. If Fetch is not just fetching external (as not in the current document) then we still need it for SVG. References within the same document must still work. Do scripts even execute in that context? How do you get blob URLs? In WebKit and Blink you can't execute any script anywhere in an SVG document. I am not sure about Gecko but this is the feedback I got. Maybe someone from Mozilla can answer this. I suppose we could have a mode for that in Fetch too, but it seems really SVG specific so I'm not sure that's warranted. Yes, it is quite SVG specific. I am fine with just dealing with it in SVG as long as possible. And I think it is not possible without changing the fetching on the requesters like img. (This is the case for CSS as well btw, which can reference SVG images - different topic.) SVG with single security origin: The SVG is not allowed to fetch any external resources. References in the same document and dataURLs, blobs are allowed. SVG as document: Allowed to fetch resources with No CORS - But: possibly CORS enabled depending on the referencing element (object, embed or iframe). Would it be possible to define it that way? If the former named elements, then use the fetching mechanism defined by these elements. Otherwise use single security origin? Could Fetch define single security origin? This sentence doesn't make sense. At least the otherwise clause in it. I'm not sure single security origin makes sense either as I think you don't want to do any fetching whatsoever. If something does a fetch, you want to return network error immediately and don't even attempt to make a connection as that could leak information. So SVG resources should have a locked down flag and when it's set SVG fetch or whatever you end up calling the wrapper will return network error rather than invoking fetch unless the URL's scheme is about, blob, or data I suppose. So first, for the first case (before otherwise) there is nothing that needs to be changed. Fetch and HTML already cover that. The second case would indeed need a flag like locked down flag. This would just allow fetching of resources in the same document, dataURLs (with lock down for the content of dataURL) and possibly blob URLs. The requester needs to set this lock down flag. So ideally it would be specified by the Fetch specification. Legacy fetching (used for image fetching) would set this flag by default. In this case no other specification but Fetch and CSS would need to change. Greetings, Dirk -- http://annevankesteren.nl/
Re: [whatwg] Blurry lines in 2D Canvas (and SVG)
On Jul 24, 2013, at 7:19 AM, Rik Cabanier caban...@gmail.com wrote: On Tue, Jul 23, 2013 at 6:20 PM, Glenn Maynard gl...@zewt.org wrote: (The below is about Canvas only; I'm not very familiar with SVG. I think they should be two separate discussions.) Agreed. Sorry to confuse the issue. On Tue, Jul 23, 2013 at 6:19 PM, Rik Cabanier caban...@gmail.com wrote: we've noticed that if you draw lines in canvas or SVG, they always end up blurry. For instance see this fiddle: http://jsfiddle.net/V92Gn/128/ This happens because you offset 1 pixel and then draw a half pixel stroke on each side. Since it covers only half the pixel, the color gets mapped to 50% gray. You can work around this by doing an extra offset of half the devicepixelratio, For Canvas, you should always add 0.5, since you're in the canvas coordinate space, before the pixel ratio is applied. That seemed like an OK idea until I thought about it some more. Doing a .5 scale will also affect your fills so a rect will now have aliased borders. Also adjusting for non-round device pixel ratio or as Kornel mentions, having transforms will still result in blurry lines (unless you do a bunch of math) This is the same coordinate system used by OpenGL and Direct3D 10 (and up), with pixels centered around 0.5x0.5. That is, a pixel sits between 0x0 and 1x1. If you're specifying the center of the line (eg. where the stroke grows outwards from), you need to add a half pixel. (When you're specifying a bounding box, such as drawImage, you don't, since you're at the edge rather than the center of a pixel.) I'm not sure if there's a way to disable antialiasing for paths. Disabling antialiasing to allow people to specify wrong coordinates only seems like it would be more confusing, though. Disabling it is not a solution. The 'crispEdges' option does this and the results look bad. The only solution is to educate people about when and why they need to add a half pixel; even if there was a way to avoid this in general (I'm not sure there is, for an API with Canvas's functionality), it's much too late to change this. I agree that we can't change this, but maybe we can add something to make it better. In PDF there is a feature called strokeAdjust that will make the stroke align to pixel boundaries. Basically, if you turn it on strokeAdjust and the stroke doesn't fill the entire pixel, that pixel isn't drawn. If there's less than a pixel total, you expand the stroke to at least a pixel. Apple has a Core Graphics function called CGGStateSetStrokeAdjust so they would be able to implement this easily. :-) Means implementations would need to take viewport, transformations of the document, transformations on elements in the DOM hierarchy, zoom level, aspect ratio of the canvas, position of the canvas in the document, transformations in the canvas and device pixel resolution into account to snap lines to the correct position on the individual device, right?Otherwise it sounds to be hard to guarantee that you don't see antialiased strokes and lines might snap more then just one device pixel. This would also be a problem for aligning shapes to each other in the canvas I guess. What happens on the next transformation after a drawing operation. Say you draw a line that was snapped to the grid and then you do scale(1.1, 1.1). Shall the implementation redraw the canvas? After all it is an pixel image. A vector based drawing format would be better suited for such a task. Greetings, Dirk
Re: [whatwg] [Canvas][WebIDL] Canvas .addText takes NoInterfaceObject argument
On Jul 3, 2013, at 7:17 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 2 Jul 2013, Dirk Schulze wrote: The methods addText() and addPathByStrokingText() [1] take the NoInterfaceObject CanvasDrawingStyle [2] as argument. I wonder if that is even possible for WebIDL since there is no way to create it and no binding to ECMAScript is exposed. Shouldn't it rather be a DrawingStyle object[3], which indeed is an interface? I didn't scan if that is the case in other places as well. The definition of NoInterfaceObject is here [4]. On Wed, 3 Jul 2013, Boris Zbarsky wrote: [NoInterfaceObject] just means that window.CanvasDrawingStyle is undefined, basically. It doesn't affect anything else. addText, as an example, takes any object that implements the CanvasDrawingStyle interface. That would include any DrawingStyle object and any CanvasRenderingContext2D object, at first glance. Boris is correct. Thanks for the clarification. Dirk -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] [Canvas][WebIDL] Canvas .addText takes NoInterfaceObject argument
Hi, The methods addText() and addPathByStrokingText() [1] take the NoInterfaceObject CanvasDrawingStyle [2] as argument. I wonder if that is even possible for WebIDL since there is no way to create it and no binding to ECMAScript is exposed. Shouldn't it rather be a DrawingStyle object[3], which indeed is an interface? I didn't scan if that is the case in other places as well. The definition of NoInterfaceObject is here [4]. Greetings, Dirk [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-path-addpathbystrokingtext [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#canvasdrawingstyles [3] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#drawingstyle [4] http://www.w3.org/TR/WebIDL/#NoInterfaceObject
Re: [whatwg] Questions regarding Path object
On Jun 24, 2013, at 8:38 AM, Jürg Lehni li...@scratchdisk.com wrote: On Jun 17, 2013, at 17:55 , Rik Cabanier caban...@gmail.com wrote: I think we need to get some browser vendors on board. What's the process to do so? However, I believe Firefox has been working on landing 'path' and there was a patch for WebKit that also landed a partial path object. I'm unsure if these ended up in shipping browsers. Would that mean it's too late? I really hope not! You can check if you see problems in WebKit nightlies or in Chrome/Chromium with the experimental flag enabled. Greetings, Dirk Best, Jürg
Re: [whatwg] [canvas] Proposal isPointInStroke(x, y)
On May 3, 2013, at 5:10 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 13 Nov 2012, Jeff Muizelaar wrote: We have recently implemented isPointInStroke(x,y) in Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=803124). This is a parallel to isPointInPath(x,y) and returns true if the point is inside the area contained by the stroking of a path. It was easily implemented on top of Direct2D, Cairo, Skia, and CoreGraphics and shouldn't be difficult for other systems. We implemented this to help support functionality needed for shumway (flash on html) Thanks for the heads-up. This is now in the spec as well. Sorry for the late interference. isPointInStroke is implemented in WebKit and Blink for quite some time and should be in release versions already. No objection from this side :) I would suggest a third argument: optional CanvasFillRule fillRule = nonzero As we have for fill. (This is implemented in WebKit and Blink as well.) Greetings, Dirk -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [canvas] Proposal isPointInStroke(x, y)
On May 4, 2013, at 5:27 PM, Dirk Schulze dschu...@adobe.com wrote: On May 3, 2013, at 5:10 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 13 Nov 2012, Jeff Muizelaar wrote: We have recently implemented isPointInStroke(x,y) in Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=803124). This is a parallel to isPointInPath(x,y) and returns true if the point is inside the area contained by the stroking of a path. It was easily implemented on top of Direct2D, Cairo, Skia, and CoreGraphics and shouldn't be difficult for other systems. We implemented this to help support functionality needed for shumway (flash on html) Thanks for the heads-up. This is now in the spec as well. Sorry for the late interference. isPointInStroke is implemented in WebKit and Blink for quite some time and should be in release versions already. No objection from this side :) I would suggest a third argument: optional CanvasFillRule fillRule = nonzero As we have for fill. (This is implemented in WebKit and Blink as well.) Sorry, the third argument doesn't make sense. I slipped into the wrong line on reading our code. Dirk Greetings, Dirk -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Why are we merging Document and HTMLDocument again?
On Mar 5, 2013, at 1:42 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Mar 5, 2013 at 12:42 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/5/13 3:30 PM, Ian Hickson wrote: I'd be fine with having a Document descendant that is used for Documents that have global scopes / browsing contexts / the works, and one that is used for Documents that don't (e.g. createDocument(), XHR); would that address this issue? It's one way to address it, yes... A lot of the stuff that's moving into Document due to this merge is desirable for the SVGWG as well - we'd like to try and eliminate the SVGDocument interface if possible, or if not, at least reduce it to its bare minimum and rely just on Document for most things. We can not eliminate SVGDocument until you want to have SVG specific attributes on Document ;). This was not the discussion on the SVG WG. But we do want to share all methods with HTMLDocument where is makes sense, which are most of them. HTMLDocument, as noted by Boris, have specific methods as well that we do not necessarily want in a general scoped Document object. Greetings, Dirk ~TJ
[whatwg] [canvas] coordinate space definition bogus?
Hi, I think the definition of coordinate space is misleading in the specification. The canvas element has two attributes to control the size of the coordinate space: width and height. This implies that the coordinate space is limited by this size. This is not the case. The coordinate space can be transformed and scaled all the time. In theory the size of the coordinate space is infinite. But the size of the surface could be defined by 'width' and 'height'. The same problem occurs with the definition of clipping regions, that by default, depend on the size of the coordinate space. A simple scale and drawing over the size of the 'width' and 'height' values demonstrate that the clipping region can not be measured by the size of the coordinate space (or it could, if it is assumed to be infinite). For clip, why isn't it possible to just say that clip() does not clip if there is no currentPath? This would at least avoid this trap. Greetings, Dirk
[whatwg] [Canvas] Behavior on non-invertable CTM
Hi,
The spec doesn't have any wording about the behavior on non-invertible CTMs on
Canvas contexts. Is it still possible to add segments to the current path once
a CTM is not invertible anymore? Does the path get rejected completely then?
Implementations are fairly different.
Here are two examples (code attached at the end of the mail as well):
http://jsfiddle.net/Dghuh/1/
http://jsfiddle.net/Dghuh/2/
Note that the path is stroked after restoring the initial CTM in both examples.
The first one does scale(0), which should make the CTM non-invertibe, WebKit
still applies lineTo and closePath for some reason. IE and FF refuse to draw
anything.
The second does setTransform(0,0,0,0,0), which should reset the CTM to a zero
matrix (again, not invertible). IE, Opera and FF draw a line to 0,0 and close
the path afterwards (which kind of makes sense, since the universe is
convoluted to one point). WebKit refuses the lineTo command and closes the path
as expected.
This is an edge case, but should still be clarified in the spec.
A possible (and maybe easiest) solution would be to refuse all values for
transformation functions that cause an invertible matrix. On the other hand,
all browsers allow setting not invertible CTMs at the moment.
Greetings,
Dirk
Example 1:
head
meta charset=utf-8
title/title
script
window.onload = function () {
var canvas = document.getElementById(canvas);
var ctx = canvas.getContext(2d);
ctx.moveTo(10,10);
ctx.lineTo(90,10);
ctx.lineTo(90,90);
ctx.lineTo(10,90);
ctx.save();
ctx.scale(0);
ctx.lineTo(45,45);
ctx.closePath();
ctx.restore();
ctx.strokeStyle= black;
ctx.stroke();
}
/script
style
/style
/head
body
canvas id=canvas/canvas
/body
Example 2:
head
meta charset=utf-8
title/title
script
window.onload = function () {
var canvas = document.getElementById(canvas);
var ctx = canvas.getContext(2d);
ctx.moveTo(10,10);
ctx.lineTo(90,10);
ctx.lineTo(90,90);
ctx.lineTo(10,90);
ctx.save();
ctx.setTransform(0,0,0,0,0,0);
ctx.lineTo(45,45);
ctx.closePath();
ctx.restore();
ctx.strokeStyle= black;
ctx.stroke();
}
/script
style
/style
/head
body
canvas id=canvas/canvas
/body
Re: [whatwg] Canvas: compositing and blending operator as enumeration?
On Jan 10, 2013, at 8:10 AM, Rik Cabanier caban...@gmail.com wrote:
On Wed, Jan 9, 2013 at 10:36 PM, Dirk Schulze dschu...@adobe.com wrote:
On Jan 9, 2013, at 9:29 PM, Rik Cabanier caban...@gmail.com wrote:
Hi Dirk,
the 'globalCompositeOperation' property takes the same syntax as the css
'mix' so I don't think an enum will work.
I am not following. What does the CSS property have to do with the canvas
attribute?
See the spec:
https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#canvascompositingandblending
For consistency, people wanted the same syntax for canvas and css.
That is fine for me. I am not asking for different values or keyword names :P
Dirk
Rik
On Wed, Jan 9, 2013 at 6:18 PM, Dirk Schulze dschu...@adobe.com wrote:
Hi,
After all the discussions about winding rules and the new introduced
enumeration for nonzero and even odd, I wonder if the the compositing
and blending modes should be two enumerations as well.
enum CanvasCompositingMode {
source-over,
source-in,
…
}
and
enum CanvasBlendingMode {
normal,
multiply,
...
}
This wouldn't actually change the behavior or definition a lot, but might
help to cleanup a bit. I am happy about other names if they are not good
enough.
Greetings,
Dirk
Re: [whatwg] Proposal: Add CanvasRenderingContext2D.fillRule with nonzero (default) and evenodd options
On Jan 9, 2013, at 11:42 AM, Rik Cabanier
caban...@gmail.commailto:caban...@gmail.com wrote:
On Wed, Jan 9, 2013 at 10:27 AM, Dean Jackson
d...@apple.commailto:d...@apple.com wrote:
On 09/01/2013, at 4:08 PM, Dirk Schulze
dschu...@adobe.commailto:dschu...@adobe.com wrote:
On Jan 8, 2013, at 9:35 AM, Rik Cabanier
caban...@gmail.commailto:caban...@gmail.com wrote:
I looked at pdf2js which is using this fillRule property. As I expected,
introduction of the property results in code like this:
eoFill: function CanvasGraphics_eoFill() {
var savedFillRule = this.setEOFillRule();
this.fill();
this.restoreFillRule(savedFillRule);
},
...
// We generally keep the canvas context set for
// nonzero-winding, and just set evenodd for the operations
// that need them.
setEOFillRule: function CanvasGraphics_setEOFillRule() {
var savedFillRule = this.ctx.mozFillRule;
this.ctx.mozFillRule = 'evenodd';
return savedFillRule;
},
restoreFillRule: function CanvasGraphics_restoreFillRule(rule) {
this.ctx.mozFillRule = rule;
},
So, for even odd winding, all this code needs to run. With my proposal, this
gets much simpler:
eoFill: function CanvasGraphics_eoFill() {
this.eoFill();
},
You can find a pull request with the needed changes to pdf2js here:
https://github.com/cabanier/pdf.js/commit/8e80b086376013a5438087714a4d2abb6fe67de1
For PDF.js it would probably be easier to set the fillRule every time right
before a fill or clip operation, then checking and storing the fill rule in
the background. This would reduce the code a lot more.
I also created patches (with test files) for WebKit and mozilla:
https://bugs.webkit.org/show_bug.cgi?id=106188
https://bugzilla.mozilla.org/show_bug.cgi?id=827053
I looked at the patch for webkit. There are two parts where I would disagree
and that are potentially confusing.
eoFill(), eoClip()
It is not obvious what these functions do and how they are different to
fill() and clip(). The name should be clear about the usage. But I don't
think that introducing two new functions to the Canvas API is a lot better
either. An alternative proposal instead of new functions or attributes could
be an optional argument for the fill() and stroke() functions. This argument
would be an enumeration of 'nonzero' and 'evenodd'.
ctx.fill(); // fill with 'nonzero'
ctx.fill('nonzero') // fill with 'nonzero' as well
ctx.fill('evenodd') // fill with winding rule 'evenodd'
I prefer this approach over new methods.
In general, I tend to agree with Rik that winding rule is a geometric
operation, rather than a context style. It's a shame that this may introduce
inconsistency (I appreciate Ian's point on that).
Thanks Dean!
Do people have an opinion on a boolean value vs an enum?
A boolean value is slightly faster to execute and type while an enum is more
descriptive.
So far, canvas has not used enum values before.
I definitely agree that an enum is more descriptive. I would not necessary
expect that EO is used a lot anyway. A Boolean on the other side can also be
easier to handle for authors. But how would we decide if 'false' stands for
even odd or nonzero? How can it be done so that it is easy to remember for
authors which Boolean to use for which fill rule?
Greetings
Dirk
The boolean argument in isPointInPath seems not to be very descriptive as
well:
boolean isPointInPath(unrestricted double x, unrestricted double y,
boolean windingRule);
It is not obvious if 'true' means 'nonzero' or 'evenodd'. I would recommend
to use an optional enumeration here, with the default value 'nonzero'.
You mentioned that the winding rule should be a part of the Path object. I
can see the use case that you want to address with it. And things like a
union path of two path object with different winding rules (as you suggested
before) is possible, as long as the union path just needs to get drawn (can
be done with compositing or masking in the implementation). But the SVG WG
would like to use the Path object as a way to share path data between Canvas
and SVG. In this case, the implementation must be able to flatten a path and
provide the path data directly. This is beyond the capability of current
graphic libraries and requires third party planarizer. This needs to be
considered before adding this functionality to the Path API.
Greetings,
Dirk
On Thu, Jan 3, 2013 at 3:38 PM, Ian Hickson
i...@hixie.chmailto:i...@hixie.ch wrote:
On Fri, 10 Jun 2011, Chris Jones wrote:
In 2D canvas, determining whether a point is inside a path is
currently always done using the non-zero winding rule. I propose
extending 2D canvas to allow determining inside-ness using the even-odd
rule.
I've added this to the spec.
On Wed, 2 Jan 2013, Dirk Schulze wrote:
There was a complain on the webkit bug report if fillRule should
Re: [whatwg] Including HTML more directly into SVG
On Jan 9, 2013, at 2:18 PM, Rik Cabanier caban...@gmail.com wrote: On Fri, Dec 28, 2012 at 8:59 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 10 Sep 2012, Tab Atkins Jr. wrote: 1. Check out http://www.xanthir.com/etc/railroad-diagrams/example.html . See all those boxes full of text in the diagrams? Looks simple, right? Just a box filled with text, with a border and background set on it. Wrong! SVG doesn't have any primitives like that. Instead, you have to position the text, measure its dimensions (or, like I've done, guess at the dimensions based on the font-size and such), then create and position an *independent* rect element behind it, so that it *looks* like there's a box with text inside of it. Well, you can just put the text in a foreignObject with a div, and style that. Your bigger problem is going to be positioning the lines on the other side of the rect/foreignObject. This would be a lot easier if I could somehow invoke the CSS box model inside of SVG, but the text element doesn't allow that. That's what foreignObject is for. I agree. When we discussed this a couple of months ago, people did not like the name. Why is HTML considered 'foreign'? Also, browser have identified multiple security issues with foreignObject. AFAIK the SVG spec doesn't mention any of them. I think a new tag in SVG is needed that just support inclusion of HTML. In addition, it needs to define the security model and allow the HTML to draw outside of its box. I guess you mean things like shadows and filter output should not be clipped? In this case the new element would not interact as some kind of iframe, but as an integral part of SVG, allowing to better mix SVG and HTML. I think this is a good way to go and should be implementable. The reason why it is not so easy to allow HTML elements to be embedded into SVG directly are the different kind of concepts. HTML elements contribute to the CSS Boxing Model with relative positioning and layout. SVG elements need information about the coordinates and dimension. While I could imagine that SVG elements can contribute to the CSS Boxing Model when they would be put into HTML content without surrounding them with an svg elements, the other way around is more difficult. Turning a relative positioned, layout based element into a coordinate, size based context is not so easy. A new element as you both describe it here can help a lot. Greetings, Dirk Closely related to this, SVG doesn't do automatic linebreaking at all. If you want text to break, you have to do it manually, not only determining the break points but also manually setting the line-spacing separation for each individual line. Again, it would be cool to invoke the CSS box model here, so we get full-power inline layout. foreignObject does that too. [...] there is an a11y tool that lets low-vision users interact better with SVG diagrams. They can print out an SVG, attach it over a pressure-sensitive touchpad, then bring up the diagram on the screen as well. Using the touchpad, they can then zoom/pan the SVG, or even ask the computer to read out text at the location they've pressed. Unfortunately, the textual semantics in SVG are pretty impoverished right now; there *aren't* any semantics, besides here is text. It seems pretty obvious that you'd sometimes want to, say, emphasize a span of text inside a larger text block in a diagram, but right now the only way to do that is by using tspan style=font-style:italic; and hoping that the reader supports enough CSS to guess that italicized text should be emphasized. How common is it for text in a diagram to be emphasised to the point where you definitely need a clear indication in a speech-synthesis rendering done in conjunction with a visual display? It seems like it'd be rare enough that the mere visual indication of italics would make it pretty obvious to the user what was going on... It would be pretty nice if you could use em or the other textual HTML elements here, for the same reason it's nice to use them in HTML rather than relying on visual presentation. In the cases where you need this, isn't foreignObject enough? 3. Related to the above, it seems useful to be able to embed special elements like input type=date, video, or details into SVG, for the same reasons you'd include them in HTML. Or MathML, indeed. Again, this seems reasonably easy with foreignObject. Which you point out: Right now, all three of the above *could* be done by using the foreignContent element. Right. :-) This is a horrible solution, though. To use foreignContent, you need to specify a width and height (and we're back to measuring or guessing at the dimensions...) and specify a namespace. This is a lot of weight to put into a document when all you want to do is include some simple text. You don't have to specify a namespace in text/html, but agreed
[whatwg] Canvas: compositing and blending operator as enumeration?
Hi,
After all the discussions about winding rules and the new introduced
enumeration for nonzero and even odd, I wonder if the the compositing and
blending modes should be two enumerations as well.
enum CanvasCompositingMode {
source-over,
source-in,
…
}
and
enum CanvasBlendingMode {
normal,
multiply,
...
}
This wouldn't actually change the behavior or definition a lot, but might help
to cleanup a bit. I am happy about other names if they are not good enough.
Greetings,
Dirk
Re: [whatwg] Proposal: Add CanvasRenderingContext2D.fillRule with nonzero (default) and evenodd options
On Jan 8, 2013, at 9:35 AM, Rik Cabanier caban...@gmail.com wrote:
I looked at pdf2js which is using this fillRule property. As I expected,
introduction of the property results in code like this:
eoFill: function CanvasGraphics_eoFill() {
var savedFillRule = this.setEOFillRule();
this.fill();
this.restoreFillRule(savedFillRule);
},
...
// We generally keep the canvas context set for
// nonzero-winding, and just set evenodd for the operations
// that need them.
setEOFillRule: function CanvasGraphics_setEOFillRule() {
var savedFillRule = this.ctx.mozFillRule;
this.ctx.mozFillRule = 'evenodd';
return savedFillRule;
},
restoreFillRule: function CanvasGraphics_restoreFillRule(rule) {
this.ctx.mozFillRule = rule;
},
So, for even odd winding, all this code needs to run. With my proposal, this
gets much simpler:
eoFill: function CanvasGraphics_eoFill() {
this.eoFill();
},
You can find a pull request with the needed changes to pdf2js here:
https://github.com/cabanier/pdf.js/commit/8e80b086376013a5438087714a4d2abb6fe67de1
For PDF.js it would probably be easier to set the fillRule every time right
before a fill or clip operation, then checking and storing the fill rule in the
background. This would reduce the code a lot more.
I also created patches (with test files) for WebKit and mozilla:
https://bugs.webkit.org/show_bug.cgi?id=106188
https://bugzilla.mozilla.org/show_bug.cgi?id=827053
I looked at the patch for webkit. There are two parts where I would disagree
and that are potentially confusing.
eoFill(), eoClip()
It is not obvious what these functions do and how they are different to fill()
and clip(). The name should be clear about the usage. But I don't think that
introducing two new functions to the Canvas API is a lot better either. An
alternative proposal instead of new functions or attributes could be an
optional argument for the fill() and stroke() functions. This argument would be
an enumeration of 'nonzero' and 'evenodd'.
ctx.fill(); // fill with 'nonzero'
ctx.fill('nonzero') // fill with 'nonzero' as well
ctx.fill('evenodd') // fill with winding rule 'evenodd'
The boolean argument in isPointInPath seems not to be very descriptive as well:
boolean isPointInPath(unrestricted double x, unrestricted double y,
boolean windingRule);
It is not obvious if 'true' means 'nonzero' or 'evenodd'. I would recommend to
use an optional enumeration here, with the default value 'nonzero'.
You mentioned that the winding rule should be a part of the Path object. I can
see the use case that you want to address with it. And things like a union path
of two path object with different winding rules (as you suggested before) is
possible, as long as the union path just needs to get drawn (can be done with
compositing or masking in the implementation). But the SVG WG would like to use
the Path object as a way to share path data between Canvas and SVG. In this
case, the implementation must be able to flatten a path and provide the path
data directly. This is beyond the capability of current graphic libraries and
requires third party planarizer. This needs to be considered before adding this
functionality to the Path API.
Greetings,
Dirk
On Thu, Jan 3, 2013 at 3:38 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 10 Jun 2011, Chris Jones wrote:
In 2D canvas, determining whether a point is inside a path is
currently always done using the non-zero winding rule. I propose
extending 2D canvas to allow determining inside-ness using the even-odd
rule.
I've added this to the spec.
On Wed, 2 Jan 2013, Dirk Schulze wrote:
There was a complain on the webkit bug report if fillRule should be part
of the graphics state or not. Did you investigate what current 2d
graphics libraries do (qt, Cairo, CG, ...)? Is it part of the graphics
state there?
I have made it be part of the graphics state in the spec; it would be
unusual in the API for it not to be. However, if this doesn't match
implementations, please let me know.
On Wed, 2 Jan 2013, Rik Cabanier wrote:
this features is not a trivial as it seems. Adding this will necessitate
updates to the algorithms that deal with paths and the outlining of
strokes and text.
Can you elaborate on what updates are needed? I couldn't see any that
actually needed to be changed.
As Dirk mentioned, instead of making it part of the graphics state, it's
more likely better to make it part of the fill or clip operator like
SVG, PDF and PostScript.
That seems like it would be inconsistent with the rest of the canvas API.
In addition, the path object will need to be extended so it can deal
with this idiom.
Can you elaborate on how this affects the Path object? It seems like it
would be somewhat orthogonal.
The easiest way to implement
Re: [whatwg] Canvas: even-odd winding rule fills
On Jan 2, 2013, at 3:40 AM, James Ascroft-Leigh j...@jwal.me.uk wrote: All, I recently discovered that a common and well understood 2D graphics operation is not supported by the 2D canvas API even though it is supported by almost every other modern 2D graphics API. This missing feature is called even-odd fill and controls how the fill region is calculated for self-intersecting paths or enclosed subpaths. Yes, that is a missing feature in Canvas. This is already implemented in Mozilla Firefox as the mozFillRule property of the 2D canvas drawing context which can take the values nonzero (default) and evenodd. The feature is used by projects such as pdf.js for rendering PDFs to the canvas. I am working on adding similar functionality to WebKit (for Apple Safari, Google Chrome and other related browsers). This is actually really easy as the backend drawing APIs already have the necessary features to support SVG rendering. The suggestion has been made that this is added as an unprefixed fillRule property and incorporated into the HTML standard. This has been mentioned on this list before but there hasn't really been much discussion. Please see the links below for more information if you are interested. * Webkit patch: https://bugs.webkit.org/show_bug.cgi?id=105508 * W3 bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19932 * pdf.js issue: https://github.com/mozilla/pdf.js/issues/2351 Post to the list if you have any comments about the proposal or if you think you can help me. There was a complain on the webkit bug report if fillRule should be part of the graphics state or not. Did you investigate what current 2d graphics libraries do (qt, Cairo, CG, ...)? Is it part of the graphics state there? Greetings, Dirk Thanks, James
Re: [whatwg] [canvas] inner shadows
On Nov 23, 2012, at 2:36 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 21 Sep 2012, Tyler Larson wrote: On Sep 20, 2012, at 6:49 PM, Ian Hickson i...@hixie.ch wrote: Can't you do this using clip() easily enough? Maybe I'm missing something important here. Can you elaborate? Here is an example of what I am talking about. http://i.imgur.com/Sy4xM.png Clip would mask something but adding an inner shadow is different and pretty difficult to reproduce when you take into account complex shapes. Ah, yeah, I see what you mean. The problem is that the canvas rendering model always renders the shadow under the shape, and uses the shape's alpha to work out where to paint the shape. What we could do is offer control that would change the shadows from rendering under the shape to rendering over the shape, or, maybe even better, have a mode that only renders the shadows. Then you could achieve these effects relatively easily (by clipping to the shape so that the shadow only renders inside the shape). Dependent if Canvas supports Filter Effects in the future or not (including SVG filters), the overlay shadow can be done with a combination of SourceAlpha and gaussian blur. There are already Canvas libraries that offer SVG Filters on Canvas. Greetings, Dirk Is this something implementors would be interested in? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [canvas] Path object
Can you please move this discussion to another thread and discuss the Path object on this thread? Greetings, Dirk On Oct 5, 2012, at 2:56 PM, Glenn Maynard gl...@zewt.org wrote: On Fri, Oct 5, 2012 at 4:17 PM, Boris Zbarsky bzbar...@mit.edu wrote: Yes, but at the cost of performance and memory usage that just doesn't seem worthwhile here. Is there really a nontrivial cost to a one-time warning, the first time a window attribute is resolved this way? (Warning once per ID would be nice, but warning once per page load serves the purpose.) It sounds like a single branch at most. And web developers get annoyed when UAs warn about various spec-compliant stuff they're doing, in my experience. I'm a web developer, and I get annoyed at not being told when I'm doing something obviously bad, so you'll have to pick which group to annoy: people who want to write reliable webpages, or those who don't. -- Glenn Maynard
Re: [whatwg] CanvasRenderingContext2D with addPath, currentPath
On Sep 28, 2012, at 12:17 PM, Rik Cabanier caban...@gmail.com wrote: On Fri, Sep 28, 2012 at 9:31 AM, Dirk Schulze dschu...@adobe.com wrote: Hi, Would it be possible to extend CanvasRenderingContext2D with the functions: void addPath(Path path); - which adds a Path object to the current path on Canvas? attribute Path currentPath; - that returns a copy of the current path, or let you replace the current path with another Path object (not live)? These could possibly also replace clip(Path), fill(Path), stroke(Path), drawSystemFocusRing(Path path...), isPointInPath(Path path…). I like the 'op(path)' operators so I'd rather not see them go. 'currentPath' should return a read-only copy (and not be live) currentPath would not be live, no. But if you really want op(Path), then it raises the question why we have path arithmetic in CanvasRenderingContext2D at all. Then it should be completely separated (which is not the case). What would be the sense for op(Path), if you have currentPath attribute? It needs to be clarified what happens for this case: var path = new Path(); path.lineTo(20,20); ctx.currentPath = path; ctx.fill(); The pendant on CanvasRenderingContext2D: ctx.beginPath(); ctx.lineTo(20,20); would do a moveTo(20,20) internally. Should Path do the same? This problem exists for fill(Path path) at the moment as well, if I did not miss a line. Qt for instance adds a moveTo(0,0) at the beginning if no current point was specified, other platforms behave differently. Yes, but the 'moveTo' would happen when you call the fill. The path itself should just be geometry. That would mean that the engine is fully aware of every operation in the Path object. If the engine relies on the underlying graphic library (which a lot of UIs do), then you are not aware of each segment anymore. Qt for instance adds a moveTo(0,0) automatically if the first added segment is a lineTo(…). One question is what happen to the current path when you call 'op(path)' since that is not defined in the current spec. I believe the current path should be ignored and only the argument drawn. That is what I would expect, but it is indeed not described yet. Dirk
Re: [whatwg] Rename the 7-arg arcTo() to ellipseTo()?
On Sep 24, 2012, at 3:50 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 24 Sep 2012, Tab Atkins Jr. wrote: You are looking at the simplest possible use-case for A/a, nearly the only case that can be done without trig, where you're starting and stopping the arc at a quarter-turn. Try virtually anything more complex, like rotating the square 45deg. Using arcTo it's still trivial - you just need to know enough trig to figure out that the corners are now at (0, 1.414), etc., and the command takes care of the rest for you. With A/a, you need to do a bit more to translate the points of the diamond into the start/end of the arc. Don't even get me started on trying to do a 5-pointed star with rounded corners. In general, if you can do a sharp corner, you can do a rounded corner with arcTo. You need no additional information. arcBetween almost always needs significantly more information. Fair enough. Anyway, my original point stands: I don't see why this would have any impact on the canvas API. The API to be consistent with is the existing path API, not the canvas one. If you did want to introduce optional arguments to the path API, though, that would be relatively trivial; just introduce a punctuation mark that means end of arguments, e.g. /. B 10,10 20,20 5 / 30,30 40,40 10 ...instead of: B 10,10 20,20 5 5 0 30,30 40,40 10 5 0 ...(where B is a command that takes the same arguments as arcTo().) Tab already noted that the SVG WG will add arc/arcTo ellipse/ellipseTo after user requests. And we would like to be as consistent with Canvas as possible. Making the path syntax more complex than it needs to be seems not to be an option for me. But you are right that it does not need to be a problem with the Canvas API. To be honest it seems very confusing to me that Canvas has arc() and ellipse() but no ellipseTo() as pendant to ellipse(). Greetings, Dirk -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Rename the 7-arg arcTo() to ellipseTo()?
On Sep 24, 2012, at 4:32 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 24 Sep 2012, Dirk Schulze wrote: Making the path syntax more complex than it needs to be seems not to be an option for me. It's definitely an option, assuming this is not a trivial statement, because it's no the only axis along which the syntax can be optimised, and it is not the axis that has been used previously. Specifically, the path syntax has clearly been optimised for terseness and power, at the expense of simplicity. And this simplicity is asked from developers over the power of the existing segments. It is already strange that not even authoring tools use a/A, neither Illustrator nor Inkscape, the most famous SVG creation tools. Nothing can quite mess up an API or language like changing optimisation function (changing design philosophy) half-way through its life. You end up with languages that feel like they have multiple personality disorder, and it ends up being much harder to learn the language than if it was consistent with itself but overall more complicated than possible. Sometimes this is the price of backwards compatibility. That is, a language that has complexity 10 throughout is easier to learn and use than a language that is half complexity 10 and half complexity 1. This is a lesson we have learnt many times on the Web, not least of which with HTML, which has lurched in many directions over its lifetime, leaving authors highly frustrated and confused. Well, we just add new segments and don't mess up the existing syntax. Authors have the freedom to choose between the path syntax they want. To be honest it seems very confusing to me that Canvas has arc() and ellipse() but no ellipseTo() as pendant to ellipse(). ellipse() exists only because arc() already had optional arguments and the resulting API had arc() been extended to support ellipse()'s use case would have been to have the radii arguments split or to have optional arguments in the middle, which is IMHO even worse than adding another method. It's an unfortunate situation, certainly. I believe you that this wash't your intention initially, but the inconsistency is the naming now. Canvas has arc and ellipse on the one side and just arcTo on the other side. On Mon, 24 Sep 2012, Tab Atkins Jr. wrote: Returning to the original subject, we don't *want* optional arguments here. Well, the canvas API has optional arguments, so there's no way to be consistent with canvas with this constraint. (This is the case even before ellipses are considered.) Yes, there have been optional arguments before. The question is just related to arcTo() and ellipseTo() they don't need to differ so much from the idea of arc() and ellipse(). We prefer using the names arc and ellipse to denote circular and elliptical variants of the commands. I think this will make the path language really ugly, assuming you're talking about the commands and not the names (as in, the strings in d= will now be long instead of one-letter commands), and I question whether this makes sense, but that's a discussion for the www-svg list. This is a separate discussion and you can definitely mail to www-svg raising this concern. At some point SVG runs out of meaningful letters :) Right now, the canvas path API is inconsistent with itself, using arc/ellipse in one place, and using arc with optional arguments in another. Specifically, it's using arc and arcTo with optional arguments, and ellipse separately, because arc couldn't be extended sanely the way arcTo could be. We would prefer to align the syntaxes of canvas path and SVG path as much as possible, to help authors translate knowledge between the two. I think it would be far more useful for SVG to be consistent with itself, have no similarity with canvas, and present a sane language, than to have SVG inconsistent with both itself and canvas, and present a fractured language that is hard to learn. Not if we have the feedback of authors that the current syntax is to complex for a lot of cases. It doesn't make sense to act against wishes of web authors. As such, we're requesting that the canvas path API change to be consistent with itself, in the direction that we prefer. I believe the canvas API is adequately consistent with itself given the constraints facing this API's evolution, and so have not changed it. I don't see the changes on SVG as a requirement for Canvas to change the API. I am just in favor for a harmonization. Canvas and SVG don't need to be two fully separate drawing languages. There is a lot of interest from web authors to use both. Greetings, Dirk -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] [canvas] CanvasRenderingContext2D with addPath, currentPath
Hi, Would it be possible to extend CanvasRenderingContext2D with the functions: void addPath(Path path); - which adds a Path object to the current path on Canvas? attribute Path currentPath; - that returns a copy of the current path, or let you replace the current path with another Path object (not live)? These could possibly also replace clip(Path), fill(Path), stroke(Path), drawSystemFocusRing(Path path...), isPointInPath(Path path…). It needs to be clarified what happens for this case: var path = new Path(); path.lineTo(20,20); ctx.currentPath = path; ctx.fill(); The pendant on CanvasRenderingContext2D: ctx.beginPath(); ctx.lineTo(20,20); would do a moveTo(20,20) internally. Should Path do the same? This problem exists for fill(Path path) at the moment as well, if I did not miss a line. Qt for instance adds a moveTo(0,0) at the beginning if no current point was specified, other platforms behave differently. Greetings, Dirk
[whatwg] isPointInPath on Path object
Hi, The interface of CanvasRenderingContext2D currently has a function called isPointInPath() with a Path object as input [1]. I wonder why this needs to be on the context interface. Wouldn't it make more sense on the interface of Path object itself? If an implementation really needs a context to get a point on a path it, it can create it on it's own. The only situation that might be reasonable would be a transform on the Canvas that an author want to cover in the Path. But for the rare case where this matters, you can create a new Path object, add your path with the transform and call isPointInPath. Furthermore, a transform() function that applies to a Path object seems to be useable as well. But that can be discussed on a different mail. Greetings, Dirk [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#2dcontext
[whatwg] Path object with transform function (was: isPointInPath on Path object)
On Sep 21, 2012, at 3:12 AM, Ian Hickson i...@hixie.ch wrote: The only situation that might be reasonable would be a transform on the Canvas that an author want to cover in the Path. But for the rare case where this matters, you can create a new Path object, add your path with the transform and call isPointInPath. Yeah, you could do that too. Furthermore, a transform() function that applies to a Path object seems to be useable as well. You can create a new Path, then add another Path to it while applying a transform, using the addPath() method. Yes, it is possible. But there are two reasons why I think that it still makes sense to use a transform function. First it seems natural to have a transform on Path object, like the CanvasRenderingContext2D already has. Both share a lot of functions, why disallow it for transforms? Second, the solution that you mention requires a copy operation. A lot of libraries would create a new path, add the other path and apply the transform afterwards. Seems unnecessary for me. Greetings, Dirk
Re: [whatwg] fxCanvas 0.2 and some remarks about canvas spec
Depending on how the Path object gets implemented, there could be a lot more benefits. E.g. the Context could be transformed without transforming the path. It would be possible to get a point at a given length on a path or the path length itself. It would be possible to get a segment on a path or replace it by another one. If the Path would store information about stroke styles, like thickness, we could also get the information if a point is on the stroke of a Path, or the bounding box surrounding a path. All this is part of SVGs path implementation and shouldn't be hard to implement for browser vendors who already support SVG. Dirk Am 16.11.2010 um 06:38 schrieb Evgeny Burzak: 2010/11/15 Samuel Ytterbrink sam...@ytterbrink.nu: hmm... Can you explain the path-object more in detail. It sounds interesting... but why shouldn't i just create a function that takes a context and do the same path commands on it instead of having a context taking a path object? In case of 1000 path nodes , path object may save good portion of time due to caching mechanism. Inside IExplorer, path is serialized so that , I can drawing even complicated curves without a hung. And technical details: CanvasPath instance has all canvas path drawings methods , plus: append(path object) clone() push(segment) pop() Path segment is just an array, for ex. [moveTo, [0,0]]. In current version nodes are saved in _stack property, but i think CanvasPath should be special array, so that i can get n-th segment as path[n]. Related methods in canvas context: beginPath() - is created new path object inside context createPath() - creates and returns path obj instance appendPath() - appends to the current path clonePath() - clones and returns path obj Evgeny
[whatwg] Canvas arcTo all points on a line
Hi, have two questions to the all points on a line part of canvas' arcTo. A short example: moveTo(50,0); arcTo(100,0, 0,0, 10); This should add a new, from p1 infinite far away, point to the subpath and draw a straight line to it. Two questions. 1) If I add lineTo(50, 50); after arcTo(..). Wouldn't it draw a quasi parallel line to the line of arcTo? Because (Xx, Yx) (mentioned in the spec) is infinite far away. That means, we will never reach this point in reality. 2) We don't allow infinite values for moveTo or lineTo, but can make this happen with arcTo. The example above would be the same as lineTo(-Infinite, 0); But we can make moveTo(-Infinite, 0) too with the example above. Just make strokeStyle transparent, use arcTo from above and you're done. And moveTo(infinite, infinite); would be possible too. thanks Dirk
Re: [whatwg] Canvas arcTo all points on a line
I believe adding an infinite far away point is wrong and insteaed nothing should be drawn at all and I would like to explain my reason: Imagine 2 vectors. One from (x1, y1) to (x0, y0) and one from (x1, y1) to (x2, y2). For moveTo(100, 0); arcTo(150,0, 50, 0, 10); the angle between the two vectors is 0. Now we want to calculate the two points on the tangents of the circle with the radius r. r is not null (first point of the specification for arcTo). Now put it to a system of equations and you won't get a solution. It's unresolveable. Why is something allowed, that is not calculateable? The next reason is, that infinite or NaN values are not alowed for lineTo and moveTo , ... . But it's possible to get support for infinte indirectly with arcTo (see comment above). And how to deal with a infinite far away point? A lineTo would never reach this point, it's infinite far away. Instead we have to draw a line parallel to the infinite long line, created by arcTo (and it's infinite long too). Please correct me if I missunderstood the specification. Dirk Am Samstag, den 27.12.2008, 10:37 +0100 schrieb Dirk Schulze: Hi, have two questions to the all points on a line part of canvas' arcTo. A short example: moveTo(50,0); arcTo(100,0, 0,0, 10); This should add a new, from p1 infinite far away, point to the subpath and draw a straight line to it. Two questions. 1) If I add lineTo(50, 50); after arcTo(..). Wouldn't it draw a quasi parallel line to the line of arcTo? Because (Xx, Yx) (mentioned in the spec) is infinite far away. That means, we will never reach this point in reality. 2) We don't allow infinite values for moveTo or lineTo, but can make this happen with arcTo. The example above would be the same as lineTo(-Infinite, 0); But we can make moveTo(-Infinite, 0) too with the example above. Just make strokeStyle transparent, use arcTo from above and you're done. And moveTo(infinite, infinite); would be possible too. thanks Dirk
