Re: [whatwg] CanvasRenderingContext2D with addPath, currentPath
The latest Safari is shipping currentPath and Blink has implemented it behind a runtime flag. Could we put this in the specification? the proposal is for a new attribute on the 2d canvas rendering context: attribute Path currentPath; This attribute would give you a non-live/copy of the current path in device space. You can also set a path, again in device space (meaning that the current CTM would not be applied). For instance: var ctx = ...getContext(2d); ctx.scale(2, 2); ctx.moveTo(10, 10); ctx.lineTo(100, 10); var p = ctx.currentPath; Path p would contain a line from (20, 20) to (200, 20) Likewise: var p = new Path(); p.moveTo(10, 10); p.lineTo(100, 10); ctx.scale(2, 2); ctx.currentPath = p; The rendering context would have a line from (10, 10) to (100, 10) On Sat, Sep 29, 2012 at 10:19 AM, Rik Cabanier caban...@gmail.com wrote: On Fri, Sep 28, 2012 at 1:19 PM, Dirk Schulze dschu...@adobe.com wrote: 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? Currentpath could still be handy if you want to copy a path from one canvas to another, or if you have existing code that you are migrating. For instance, if you're going to use hit regions, it would be handy to have. 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(…). Yes, but only once you start executing the path in the canvas context. However, if we define a path as an 'atomic' operation, I agree that the 'moveTo' should be added to the path. 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] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 10/31/13 7:42 AM, Anne van Kesteren wrote:
On Wed, Oct 23, 2013 at 4:47 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/22/13 7:00 AM, Anne van Kesteren wrote:
So do you think we should add getElementById() to ParentNode in DOM?
I actually do, yes.
http://dom.spec.whatwg.org/#parentnode
We can't have nice things. :(
When I tried to check this in, our automated tests failed while running
the regression tests for jQuery 1.2.6. This library has code like so:
var elem = ret[ret.length-1];
// Try to do a global search by ID, where we can
if ( m[1] == # elem elem.getElementById
!jQuery.isXMLDoc(elem) ) {
// Optimization for HTML document case
var oid = elem.getElementById(m[2]);
// etc
} else {
// walk the kids of elem
}
so if you have this markup:
divspan id=x/span/div
div/div
script
alert($(div #x).length);
/script
you end up with ret being the list of divs in the code above. Then if
the last div has a getElementById function that gets called and in this
case returns null, so 0 is alerted. If it doesn't, then it walks the
kids and finds the span, so 1 is alerted.
I can obviously adjust our in-tree tests, but this test was part of
jQuery's regression test suite, and I would be slightly surprised if
there's no one out there using jQuery 1.2.6 (or later, up until the code
went away; I did check that jQuery 1.10.2 no longer has the code cited
above) and if they don't run into this issue. :(
Anyone think otherwise?
-Boris
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 11/1/13 9:59 PM, Boris Zbarsky wrote: We can't have nice things. :( Though nothing I know of so far is stopping us from adding getElementById on DocumentFragment... for what that's worth. -Boris
Re: [whatwg] CanvasRenderingContext2D with addPath, currentPath
(Please don't cross-post to the WHATWG list and other lists, as it causes thread fragmentation when people not on the WHATWG list respond.) On Fri, 1 Nov 2013, Rik Cabanier wrote: The latest Safari is shipping currentPath and Blink has implemented it behind a runtime flag. Could we put this in the specification? What's the use case? I intentionally didn't add this to the spec when I was adding the last set of path-related features, because it seems entirely redundant with Path objects. I thought we'd want people to move away from using the implicit path, rather than making it more powerful. the proposal is for a new attribute on the 2d canvas rendering context: attribute Path currentPath; This attribute would give you a non-live/copy of the current path in device space. If it returns a copy, it should be a method. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] CanvasRenderingContext2D with addPath, currentPath
On Fri, Nov 1, 2013 at 7:22 PM, Ian Hickson i...@hixie.ch wrote: (Please don't cross-post to the WHATWG list and other lists, as it causes thread fragmentation when people not on the WHATWG list respond.) On Fri, 1 Nov 2013, Rik Cabanier wrote: The latest Safari is shipping currentPath and Blink has implemented it behind a runtime flag. Could we put this in the specification? What's the use case? It would be a very fast way to set a cached path in the graphics state. There's no need to apply the current transform and the underlying path object can quickly be copied since it replaces the current path (as opposed to adding to it) I intentionally didn't add this to the spec when I was adding the last set of path-related features, because it seems entirely redundant with Path objects. I thought we'd want people to move away from using the implicit path, rather than making it more powerful. The intent is to move away from path to describe filled or stroked regions. the proposal is for a new attribute on the 2d canvas rendering context: attribute Path currentPath; This attribute would give you a non-live/copy of the current path in device space. If it returns a copy, it should be a method. That's a problem :-( Shipping Safari has an attribute and it duplicates the path when ask for the current path.
