W3C home > Mailing lists > Public > public-canvas-api@w3.org > April to June 2011

Re: hit testing and retained graphics

From: Charles Pritchard <chuck@jumis.com>
Date: Thu, 23 Jun 2011 20:24:31 -0700
Message-ID: <4E04036F.4000004@jumis.com>
To: Frank Olivier <Frank.Olivier@microsoft.com>, Richard Schwerdtfeger <schwer@us.ibm.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Cynthia Shelly <cyns@microsoft.com>, david.bolter@gmail.com, Mike@w3.org, public-canvas-api@w3.org, public-html@w3.org, public-html-a11y@w3.org
On 6/23/2011 8:18 PM, Cameron McCormack wrote:
>> I've personally implemented SVG, and I've worked with other
>> developer's implementations of SVG which worked atop canvas. I've also
>> worked with issues where method calls had unfortunate overhead. In all
>> cases, it's a big help to have the Canvas implementation recognize
>> normalized SVG strings. And it's relatively inexpensive to add to
>> Canvas implementations.
> (Sorry to belabour this point.)
> I should think it would be easy enough for the implementation to support
> full SVG strings.  After all, if getCurrentPath returns a normalised
> string, and the current path your create on the canvas context included
> any arc commands, then your implementation will need to have code to
> flatten them down to Béziers or straight line segments.  On the other
> hand, if you perform no normalisation, the mapping from the path as
> built up using lineTo/arcTo/etc. to the path data string that you return
> is simple.
It's substantially more code to parse such strings and the code execution
paths are more simple when generating them. We're looking at 2x more code
required by vendors. arc is a particularly controversial piece of code.

It's not that it's -that- expensive or -that- difficult, but it's not 
in the UA environment, it can be done in scripting, and it is 2x more code
in -all- implementations if it's required.

>>> I think the whole point of SVG exposing path data as either
>>> normalised or un-normalised is that user script may find it easier
>>> not to have to deal with both relative and absolute commands, arcs,
>>> etc.
>> And the implementation. It's a lot of extra work, and it's not really
>> necessary, as it can be handled at other points in the pipeline.
> This is only the case if you somehow disallow authors from calling
> arcTo.  Authors can construct paths with canvas now that include arc
> commands.  If you want to return normalised path data, the
> implementation needs to do work to flatten this.  If you return
> unnormalised path data, you don’t have to do any work.

Implementations of SVG should be returning normalized paths; they're easier
on the CPU and they're more portable. You do not need to disallow arcTo;
in many implementations (traditionally, anyway), arcTo is decomposed
into curves.
Received on Friday, 24 June 2011 03:25:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:10:30 UTC