[whatwg] Canvas hit region feedback
ian at hixie.ch
Tue Jul 17 13:48:26 PDT 2012
On Thu, 5 Jul 2012, Edward O'Connor wrote:
> Currently, there are only two ways to invoke the "clear regions that
> cover the pixels" algorithm: by calling either addHitRegion() or
> clearRect(). Authors should be able to explicitly remove a hit region as
> well, with a removeHitRegion(id) method.
> Consider a region of a canvas which the author would like to toggle
> between clickable and non-clickable states without drawing. Maybe
> they're indicating clickability by drawing a different outline around
> the region without actually redrawing the region itself, or perhaps
> there is no visible indication that the region's clickability is
> changing. Such an author should be able to straightforwardly achieve
> this without redrawing the region (as clearRect would require) and
> without installing a dummy hit region (as addHitRegion would require).
On Thu, 5 Jul 2012, Charles Pritchard wrote:
> There's also just removing the element from the DOM. Yes, I'd like a
> removeHitRegion(Element) feature; though I can skate by with the empty
> addHitRegion method.
I don't follow this proposal.
> I've not seen a response from you regarding the issues that Richard and
> Steve have brought up around the lightweight nodes feature-proposal. It
> seems relevant to the method signature of removeHitRegion.
I checked the list but didn't see any recent relevant e-mails from anyone
named Richard or Steve. If they filed bugs, I hope to get to those soon;
I've been focusing on e-mail for a while to get the e-mail pile under
control after having neglected it for too long.
Re: using backing bitmaps for hit testing:
On Fri, 6 Jul 2012, Rik Cabanier wrote:
> 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
That's an interesting idea. I haven't added this yet, but it seems like
something we should definitely keep in mind; if it turns out that the hit
region API is popular, it would definitely be a logical next step.
On Sat, 7 Jul 2012, Dean Jackson wrote:
> 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.
Certainly implementations are welcome to use a hit region list with fine
paths, rather than pixels, so long as the effect is equivalent.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg