Re: [whatwg] isPointInPath v. set of pixels in canvas hit regions
On Thu, Jul 5, 2012 at 1:05 PM, Edward O'Connor wrote: > As things currently stand in the spec, implementations basically need to > keep N+1 bitmaps per canvas, where N is the number of hit regions. I > doubt any implementors would be enthusiastic to implement hit regions > like this. From a WebKit perspective, we'd much prefer keeping a Path > for each hit region, and then simply using isPointInPath for hit > testing. This also implies that the current piggybacking of "Clear > regions that cover the pixels" in clearRect() could go away. Yay! :) Bog-standard hit-testing algorithms apply. Keep a single extra canvas around, draw each region into it with a different color. When you're hit-testing, just see what color that pixel is, and look up which region is associated with it. This is extremely fast and simple to implement, and has all the right properties - the "topmost" region for a given pixel is the one returned. ~TJ
Re: [whatwg] isPointInPath v. set of pixels in canvas hit regions
On Jul 5, 2012, at 10:06 PM, Ian Hickson wrote: >> I think its up to the author to manage their set of paths appropriately, >> independently from the drawing operations. > > Having the drawing mechanism work in a tightly integrated fashion with the > region code IMHO helps authors avoid bugs. You don't have to track which > regions you've defined, you just make sure to draw the regions while > you're drawing the paths and it all Just Works. Not having to track the > regions is the entire point of how this API was designed -- it's also the > main differentiating factor between this API's design and the design of > hit testing in retained-mode APIs such as SVG. It's a poor design you've settled on: the purpose of these methods is to associate path information with DOM nodes. Path information is retained in relationship to DOM nodes as part of the integration of Canvas and DOM. It's supposed to be like SVG because we want to retain DOM nodes with vector data to meet accessibility needs. -Charles
Re: [whatwg] isPointInPath v. set of pixels in canvas hit regions
On Thu, 5 Jul 2012, Simon Fraser wrote: > On Jul 5, 2012, at 2:25 PM, Ian Hickson wrote: > > On Thu, 5 Jul 2012, Edward O'Connor wrote: > >> > >> As things currently stand in the spec, implementations basically need > >> to keep N+1 bitmaps per canvas, where N is the number of hit regions. > >> I doubt any implementors would be enthusiastic to implement hit > >> regions like this. From a WebKit perspective, we'd much prefer > >> keeping a Path for each hit region, and then simply using > >> isPointInPath for hit testing. This also implies that the current > >> piggybacking of "Clear regions that cover the pixels" in clearRect() > >> could go away. Yay! :) > > > > You only need one bitmap to implement the hit testing. > > > > (Or you can do it using paths, sure. The effect is the same, but it's > > probably quicker to use a bitmap.) > > I don't think the spec should be written with a particular > implementation in mind, nor should it dictate one. I agree it shouldn't (and doesn't) dictate one. But it's crazy to not consider implementations at all when writing a spec. That way lies madness like requiring O(N^2) algorithms and solving the halting problem and all kinds of other disasters (all of which I've seen in real proposals). > I also strongly object to having to update this hit testing bitmap > and/or path set on drawing operations like clearRect(). That will > potentially hurt performance. How so? If it's a path set, you just add a rectangle (you can keep the list of shapes down by occasionally running pruning algorithms to remove shapes entirely contained by later ones). If it's a bitmap, it's even easier; you just wipe the rectangle in the bitmap. > I think its up to the author to manage their set of paths appropriately, > independently from the drawing operations. Having the drawing mechanism work in a tightly integrated fashion with the region code IMHO helps authors avoid bugs. You don't have to track which regions you've defined, you just make sure to draw the regions while you're drawing the paths and it all Just Works. Not having to track the regions is the entire point of how this API was designed -- it's also the main differentiating factor between this API's design and the design of hit testing in retained-mode APIs such as SVG. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] isPointInPath v. set of pixels in canvas hit regions
On Jul 5, 2012, at 2:25 PM, Ian Hickson wrote: > On Thu, 5 Jul 2012, Edward O'Connor wrote: >> >> As things currently stand in the spec, implementations basically need to >> keep N+1 bitmaps per canvas, where N is the number of hit regions. I >> doubt any implementors would be enthusiastic to implement hit regions >> like this. From a WebKit perspective, we'd much prefer keeping a Path >> for each hit region, and then simply using isPointInPath for hit >> testing. This also implies that the current piggybacking of "Clear >> regions that cover the pixels" in clearRect() could go away. Yay! :) > > You only need one bitmap to implement the hit testing. > > (Or you can do it using paths, sure. The effect is the same, but it's > probably quicker to use a bitmap.) I don't think the spec should be written with a particular implementation in mind, nor should it dictate one. I also strongly object to having to update this hit testing bitmap and/or path set on drawing operations like clearRect(). That will potentially hurt performance. I think its up to the author to manage their set of paths appropriately, independently from the drawing operations. Simon
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Fri, Jun 29, 2012 at 4:24 PM, Ian Hickson wrote: > On Tue, 21 Feb 2012, Glenn Maynard wrote: > > > > I don't think the existence of implicit submit should depend on platform > > conventions, though, for interop on forms without visible submit > > buttons. The form implicit submit takes is a platform convention, but it > > should be required to exist in some form or another. > > User agents aren't actually required to let users input anything, so it > doesn't make much sense to require submission be possible... > This is only relevant for UAs which don't care if forms are usable, which is most of them. If forms are expected to work in the first place, then there needs to be an implicit submit mechanism. Every browser I'm aware of has one, and lots of pages depend on this, so it seems like this should be required somewhere (even if it's conditional upon something like "if user form entry is supported"). -- Glenn Maynard
Re: [whatwg] isPointInPath v. set of pixels in canvas hit regions
On Thu, 5 Jul 2012, Edward O'Connor wrote: > > As things currently stand in the spec, implementations basically need to > keep N+1 bitmaps per canvas, where N is the number of hit regions. I > doubt any implementors would be enthusiastic to implement hit regions > like this. From a WebKit perspective, we'd much prefer keeping a Path > for each hit region, and then simply using isPointInPath for hit > testing. This also implies that the current piggybacking of "Clear > regions that cover the pixels" in clearRect() could go away. Yay! :) You only need one bitmap to implement the hit testing. (Or you can do it using paths, sure. The effect is the same, but it's probably quicker to use a bitmap.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] isPointInPath v. set of pixels in canvas hit regions
On Jul 5, 2012, at 1:05 PM, Edward O'Connor wrote: > Hi, > > As things currently stand in the spec, implementations basically need to > keep N+1 bitmaps per canvas, where N is the number of hit regions. I > doubt any implementors would be enthusiastic to implement hit regions > like this. From a WebKit perspective, we'd much prefer keeping a Path > for each hit region, and then simply using isPointInPath for hit > testing. This also implies that the current piggybacking of "Clear > regions that cover the pixels" in clearRect() could go away. Yay! :) I couldn't agree more. The hit testing code from SVG in WebKit could easily be reused by the Canvas implementation. I believe the rationale for bitmap backing was based on an assumption that it would be easier for authors. I've consistently argued against this assumption. -Charles
[whatwg] isPointInPath v. set of pixels in canvas hit regions
Hi, As things currently stand in the spec, implementations basically need to keep N+1 bitmaps per canvas, where N is the number of hit regions. I doubt any implementors would be enthusiastic to implement hit regions like this. From a WebKit perspective, we'd much prefer keeping a Path for each hit region, and then simply using isPointInPath for hit testing. This also implies that the current piggybacking of "Clear regions that cover the pixels" in clearRect() could go away. Yay! :) Ted
Re: [whatwg] Removing hit regions without calling clearRect() or addHitRegion()
There's also just removing the element from the DOM. Yes, I'd like a removeHitRegion(Element) feature; though I can skate by with the empty addHitRegion method. I've not seen a response from you regarding the issues that Richard and Steve have brought up around the lightweight nodes feature-proposal. It seems relevant to the method signature of removeHitRegion. On Jul 5, 2012, at 9:40 AM, Edward O'Connor wrote: > Hi, > > Currently, there are only two ways to invoke the "clear regions that > cover the pixels" algorithm: by calling either addHitRegion() or > clearRect(). Authors should be able to explicitly remove a hit region as > well, with a removeHitRegion(id) method. > > Consider a region of a canvas which the author would like to toggle > between clickable and non-clickable states without drawing. Maybe > they're indicating clickability by drawing a different outline around > the region without actually redrawing the region itself, or perhaps > there is no visible indication that the region's clickability is > changing. Such an author should be able to straightforwardly achieve > this without redrawing the region (as clearRect would require) and > without installing a dummy hit region (as addHitRegion would require). > > > Thanks, > Ted
[whatwg] Removing hit regions without calling clearRect() or addHitRegion()
Hi, Currently, there are only two ways to invoke the "clear regions that cover the pixels" algorithm: by calling either addHitRegion() or clearRect(). Authors should be able to explicitly remove a hit region as well, with a removeHitRegion(id) method. Consider a region of a canvas which the author would like to toggle between clickable and non-clickable states without drawing. Maybe they're indicating clickability by drawing a different outline around the region without actually redrawing the region itself, or perhaps there is no visible indication that the region's clickability is changing. Such an author should be able to straightforwardly achieve this without redrawing the region (as clearRect would require) and without installing a dummy hit region (as addHitRegion would require). Thanks, Ted
[whatwg] [JavaScript / Web ECMAScript] Dropping the “escaped reserved words” compatibility requirement
http://mathias.html5.org/specs/javascript/#escaped-reserved-words says: > JavaScript implementations must support ECMAScript identifiers that unescape > to a reserved word, as long as at least one character is escaped using a > Unicode escape sequence. > > For example, var var; throws a syntax error, but e.g. var v\u0061r; works > fine. > > Subsequent use of such identifiers must also have at least one character > escaped (otherwise the reserved word will be used instead), but it doesn’t > have to be the same character(s) that were originally used to create the > identifier. > > For example, var v\u0061r = 42; alert(va\u0072); alerts 42. One year ago, all browsers except IE fulfilled this compatibility requirement. Half a year ago Firefox dropped this non-standard addition (https://bugzilla.mozilla.org/show_bug.cgi?id=694360) and hasn’t seen any compatibility issues since. Has the time come to drop this compatibility requirement?
