[whatwg] Canvas hit region feedback

[Ian Hickson]

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).

Done.


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 
> canvas.

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.   `._.-(,_..'--(,_..'`-.;.'