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

On 07/07/2012, at 10:11 AM, Charles Pritchard <chuck@jumis.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.

We're aware of this technique, but it has a couple of obvious issues:

1. It requires us to create a duplicate canvas, possibly using many MB of RAM. It's generally going to be less memory to keep a list of geometric regions. And performance won't be terrible if you implement some spatial hashing, etc.

2. It doesn't allow for sub pixel testing. In your algorithm above, only one region can be at a pixel (which also means it isn't our standard drawing code with anti-aliasing). Consider a zoomed canvas, where we might want more accurate hit testing.

Dean

Received on Saturday, 7 July 2012 00:41:09 UTC