[whatwg] Canvas hit regions feedback

[Ian Hickson]

On Fri, 6 Jul 2012, Maciej Stachowiak wrote:
> On Jul 5, 2012, at 11:28 PM, Tab Atkins Jr. <jackalmage at gmail.com> 
> wrote:
> > On Thu, Jul 5, 2012 at 1:05 PM, Edward O'Connor <eoconnor at 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.
> 
> It also doubles the memory cost of the canvas if you use hit regions, 
> which is likely much more than path-based hit testing would cost.

Indeed, as with many cases where there are multiple ways to implement 
something, the different implementation strategies have different 
tradeoffs.


On Fri, 6 Jul 2012, Rik Cabanier wrote:
> On Fri, Jul 6, 2012 at 5:40 PM, Dean Jackson <dino at apple.com> 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.
>
> 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 http://www.opengl.org/archives/resources/faq/technical/selection.htm)

That would be one of the possible implementations, as far as I can tell.


On Wed, 25 Jul 2012, Steve Faulkner wrote:
>
> From my reading of the hitregion() [1] section of the spec it is unclear 
> to me whether click events work on unbacked regions

I'm not sure what you mean by "work". Can you elaborate?


> It is clear that mouse move events can be used, but will developers be 
> able to detect and make use of click events on backed regions?

The spec doesn't distinguish between the types of mouse events. See the 
section starting around here:

   http://www.whatwg.org/specs/web-apps/current-work/#dom-mouseevent-region


On Thu, 26 Jul 2012, Steve Faulkner wrote:
> 
> In this case unbacked regions can be used to designate interactive 
> regions, but the interactivity is confined to mouse based events, as the 
> region is not associated with a DOM element that can receive focus.

The specification describes a mechanism by which hit regions that do not 
have explicit controls are indistinguishable to the user from regions that 
do have explicit controls (and indeed, from any other element in the DOM).

See the section in the spec that starts "Each hit region should be handled 
in a fashion equivalent to a node in a virtual DOM tree".

In particular, this means that accessibility tools that use a separate 
accessibility tool focus (e.g. the VoiceOver focus), and touch devices 
that provide haptic feedback, should work fine. Users who are keyboard- 
bound but unable to use an accessibility tool are screwed, but then 
they're screwed anyway since not everything that's interactive is 
focusable even at the best of times. :-( (I speak as one such user.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'