Re: Basic code examples for pointer regions

On 11/14/11 3:48 PM, Jonas Sicking wrote:
> On Sat, Nov 12, 2011 at 8:50 AM, Charles Pritchard <chuck@jumis.com 
> <mailto:chuck@jumis.com>> wrote:
>
>
>     Again, drawEars could be simplified in its current form, but if I
>     were making minimal changes, I'd have a few extra if statements.
>
>     Example (for line 641):
>     if(onlyPath) ctx.closePath(); else ctx.beginPath();
>     ...
>     if(!onlyPath) { ctx.fill(); ctx.stroke(); }
>
>     These hooks end up making debugging a little easier and more fun,
>     because more functionality is exposed throughout the program.
>     Now, with the onlyPath flag added in, I can do things like setup a
>     background or a shadow or do other color-effects with the path.
>
>     You can easily colorize the clickable regions. For debugging or as
>     another use mode.
>
>
> So it sounds to me that if your object is drawn using a single path, 
> you'd prefer to use setPathForElement since it's just a single line of 
> additional code to get hit-testing.
>

Yes, when the active path corresponds to the pointer region, I'd prefer 
to just use the single line of code rather than a before and after line.


> If your object is drawn using multiple paths, you'd prefer to go 
> through what sounds like fairly complex operations to merge those 
> paths into a single path which you could then use together with 
> setPathForElement.

I demonstrated two very simple edits to be performed in the drawEars method.
Is there another sample application you'd like me to take and edit? I'm 
happy to use pastebin to post changes.

I'm worried that there's a mis-communication, as my edits to Blob Sallad 
[sic] were not complex.

> If your object is drawn using text or drawImage function, you'd set up 
> hit-testing specific paths and call setPathForElement.
That's correct, I'd issue a single rect() command based on the image 
and/or text bounds.
In practice, in most cases, I have measureText calls close to the 
fillText command.

As for an image -- the image might be special -- for some images I might 
setup specific paths
much as one would setup an image map. But I've never had that come up... 
I rarely make images clickable.
It's typically a button effect behind the image that's clickable. Kind 
of like <button><img /></button>

> Based on this. It sounds like you'd only have fewer lines of code 
> added, and fewer lines of code changed in the first scenario. While 
> you can get the second and third scenario working with 
> setPathForElement, it seems to me to require more changes and more 
> additions.
Would you like me to hunt down more baseline Canvas examples?
In the other scenarios, the data is quite likely already available -- 
Canvas is a low-level API.

>
> If that's the case, I don't understand why setPathForElement is the 
> preferred option. Are you simply hoping that the first scenario is 
> common enough that the wins there outweigh the losses for the other 
> scenarios?
I suspect that you're over-estimating the losses.
In most worst-case case scenarios, I'd have two lines of code for 
setPathForElement; one to setup the rect.

> Am I missing or misunderstanding something?

There are several motivations:

It's my preference to be [easily] able to set my path regardless of the 
drawing.
When I use rounded rectangle buttons, I'd prefer to set the pointer 
region to a simple rectangle.

I'd prefer to make minimal changes to existing Canvas implementations 
and existing code bases, doing as few insertions as I can.
Overall, I think that using setPathForElement will require substantially 
less patching for implementers and coders.

It's also quite in-line with low level coding. We expect to be working 
with paths. That's what we're doing :-)

I think Frank's coding example for beginElement shows how easily 
beginElement could be misused
or otherwise used inefficiently. Efficiency is an issue here.

Effectiveness is another issue. I suspect it's far more effective to 
have a single path (with it's many sub-paths) on the stack
and sharable with ATs than it is to have a more complex collection of paths.

Those are some of the reasons. But again, focusing purely on the author, 
I do think setPathForElement is a better choice,
though I'm not particularly fond of the name.

Do you think it would make sense to simply use the existing "checkbox" 
example code (from the spec) for this discussion?
The most difficult part of putting the case forward is selecting code 
that we can agree is sufficient/appropriate.

-Charles