On Thu, Jul 5, 2012 at 11:28 PM, Tab Atkins Jr. <[email protected]>wrote:
> On Thu, Jul 5, 2012 at 1:05 PM, Edward O'Connor <[email protected]> > 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
