W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2012

Re: [whatwg] isPointInPath v. set of pixels in canvas hit regions

From: Rik Cabanier <cabanier@gmail.com>
Date: Fri, 6 Jul 2012 16:56:57 -0700
Message-ID: <CAGN7qDCKAMRoHVyU9=jaAJYpR65PK=MoBZ383xrcCx79xahm_w@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: whatwg@lists.whatwg.org, Edward O'Connor <eoconnor@apple.com>
On Thu, Jul 5, 2012 at 11:28 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Thu, Jul 5, 2012 at 1:05 PM, Edward O'Connor <eoconnor@apple.com>
> 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.
Yeah, this is the standard way of doing hit-testing.
However, one important use case is that this can be done with nested canvas
elements. Most (if not all) games, will use off-screen canvas elements to
draw elements which can then be reused.
The programmer will creates hit test canvas elements which are then
composited similarly to the off-screen canvases.

It seems that the additions that Ian made does not cover this use case
unless there's a way to extract the hit regions from a canvas and then
apply/remove them (with a possible matrix manipulation) to/from another

Received on Friday, 6 July 2012 23:57:27 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:14 UTC