Re: draft of hit testing on active regions (actually paths) in canvas

This example spreads beginElement out over a large area of method calls
when only the first rect() affects its behavior.

In thread:

On 10/31/11 4:46 PM, Frank Olivier wrote:
> When drawing the checkbox:
The path does not need to be re-associated each time the checkboxes are 
drawn.
They're not moving anywhere. It'd be far more efficient to set their 
region only once,
in this demo.



> // Rendering code
>
> ctx.beginElement(checkboxA);     //Tell the canvas context that all 
> non-fully-transparent pixels that we are rendering from this point on 
> represents the clickable area for the checkbox UI
>
> // Draw a background for the checkbox
>
> ctx.fillStyle = 'white';
>
> ctx.rect(0, 0, 100, 20);
>
> context.fill();
>
It's done right here.
endElement();
Or move the beginElement(checkboxA) to this place.

There's no reason to keep recording unless the subsequent drawing 
commands are intended to be serialized into the DOM (SVG) or exposed to 
the scripting environment.

> // Draw the actual checkbox
>
> ctx.rect(5, 5, 10, 10);
>
> ctx.stroke();
>
> if (checkboxA.checked)
>
> {
>
>   ctx.fillStyle = 'black';
>
>   ctx.fill();
>
> }
>
> ctx.fillText('checkbox', 20, 10);
>
> endElement(checkboxA); //We are done with element rendering
>
Why wait until here? In typical HTML practice, the beginElement call 
would be run right before drawing the checkbox, not at the time that the 
area is cleared.

Note that fillText ought to be treated as a rectangle, not a path.


> The UA/magnifier would associate any pixels rendered from 
> beginElement() to endElement() with the fallback dom element; the 
> fallback dom element 'owns' those pixels on the screen. To resolve 
> overlap, last write wins. (Implementation note: A UA could use a 
> bitmap to associate pixels with fallback dom elements. A value of 0 in 
> that bitmap could mean 'no association'; value 1 could mean 'first 
> element in the fallback dom element lookup table', etc.)
>

This doesn't jive well with sending information to ATs. Paths are quite 
a bit more appropriate.
Also, pointer events are not so particular, and if they are, that's 
something the author should handle; as I noted with the fillText method.

The dom does not "own" the pixels. It listens on the various paths. 
Those paths may not match the on-screen pixels with "exact" precision.


> Between beginElement() and endElement(), the UA would keep track of 
> the extent of the pixels that are touched by drawing operations; it 
> would use this to compute the bounding rectangle when a magnifier asks 
> for the element's extent.
>
This would be costly on the UA; I'd recommend tracking the extent of the 
area modified, not the actual pixels.
If I have an image that is half-transparent, and I use drawImage, I'd 
want the whole size of the image to be calculated, not just the half 
that is opaque.

Otherwise you have to run a magic-wand style search (a flood fill) on 
every drawImage command, and that'd be a bad thing.

> At some point in the future, when my canvas bitmap no longer has that 
> checkbox visible:
>
>                ctx.eraseElement(checkboxA); //Clear all pixels 'owned' 
> by checkboxA
>
>                (This imo assumes that you are removing or disabling 
> the corresponding DOM checkbox input element)
>

Clear all paths "associated" by checkbox A.

> All the pixels that were associated with checkboxA would now be 
> unassociated with any fallback dom element.
>
> eraseElements() does the same, but for all fallback dom elements.
>

I'm concerned that fallback is now a complete misnomer.

subtree, subdom, descendant or some other language seems more appropriate.

> I could (potentially) also clear some of the pixels that are 
> associated with a corresponding canvas element:
>
> ctx.beginElement(null);   //Tell the canvas context that all 
> non-fully-transparent pixels that we are rendering from this point on 
> should not be part of any element
>
> ctx.fillStyle = 'white';
>
> ctx.rect(0, 0, 100, 100);
>
> context.fill();
>
> endElement(checkboxA); //We are done with element rendering
>
Let's veto this one.


-Charles