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 22:58:00 -0700
Message-ID: <CAGN7qDAH4xFdyV-xSLFCzdCHNtJ_oH-5U18AQAxpyWzVy+vabQ@mail.gmail.com>
To: Dean Jackson <dino@apple.com>
Cc: whatwg@lists.whatwg.org, "Tab Atkins Jr." <jackalmage@gmail.com>, Edward O'Connor <eoconnor@apple.com>
On Fri, Jul 6, 2012 at 5:40 PM, Dean Jackson <dino@apple.com> wrote:

> 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.
Wouldn't thess problems go away if you use an OpenGL/DirectX backend to
Canvas like so many browsers are doing?
That way, you only need the display list for hit testing and just render
the region for hit testing (ie

Received on Saturday, 7 July 2012 05:58:30 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:43 UTC