Re: hit regions

On 8/21/2012 7:57 AM, Benjamin Hawkes-Lewis wrote:
> On Tue, Aug 21, 2012 at 3:52 PM, Charles Pritchard <chuck@jumis.com> wrote:
>> On 8/19/2012 9:55 PM, Rik Cabanier wrote:
>>>> A key design goal, as I understand it, was to avoid turning canvas into
>>>> a retained mode API. The author is responsible for managing any object
>>>> graph;
>>>> canvas is just a display.
>>> Isn't the new "current default path" a step towards retained graphics?
>>
>> We went through this discussion at length on public-canvas-api.
>>
>> At the point that authors take responsibility for managing the DOM, they've
>> departed from the strict sense of a bitmap API and are now in the world of
>> ARIA.
>> ARIA+DOM is a retained mode API.
> Yes, effectively authors must manage two representations of their
> abstract interface:
>
>     - canvas bitmaps
>     - DOM
>
> The WHATWG hit region feature provides the weakest possible binding
> between the two.
>

I believe the hit region feature we came up with in public-canvas-api to 
be simpler [and "weakest" in a positive sense]; the WHATWG feature 
requires that the implementation support editing of the region after 
binding, via items like clearRect .
Our proposal within the public-canvas-api mandates that the binding be 
static, and that the author must regenerate a path if they want to 
change the binding.

This is an important point both in terms of implementation complexity 
but also in terms of work that Canvas authors need to do in addition to 
their current workflow.

I've highlighted these differences in the past.
A separate proposal had suggested we have begin() and end() wrappers 
around drawing calls.

I'd like to suggest this discussion be moved over to the 
public-canvas-api mailing list.
http://lists.w3.org/Archives/Public/public-canvas-api/

-Charles

Received on Tuesday, 21 August 2012 15:10:59 UTC