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

[Rik Cabanier]

On Thu, Jul 5, 2012 at 11:28 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:

> On Thu, Jul 5, 2012 at 1:05 PM, Edward O'Connor <eoconnor at 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
canvas.

Rik