Re: hit testing and retained graphics

Hi, Rob-

Robert O'Callahan wrote (on 7/11/11 11:52 PM):
> Doug seems to be proposing a few different things:
> 1) a canvas-like object that reimplements the canvas 2D context API to
> output an SVG DOM subtree instead
> 2) attaching canvas buffers to SVG elements so you can draw into them as if
> they're canvases
> 3) some way to get SVG elements into the canvas shadow tree and have them be
> rendered as well

Yes, that's a pretty good summary, thanks.


> I don't understand #3 very well, partly because it's not specified how those
> elements would participate in rendering. Why not just put the SVG elements
> over or under the canvas? They'll be rendered and accessible.

As I understand it, once the user is in the subtree, they will need to 
get at the elements in question (and thus the geometry) as part of the 
current focus ring.  There seems to be a need to add them into this 
navigation order by inclusion or reference.  It's possible that's not a 
critical aspect of what Charles and Rich proposed, but that was my 
reading of it, so this aspect of the proposal was aimed at that (though 
I do mention I saw it as optional).

Rendering the SVG above or below the canvas, as appropriate, would 
otherwise solve that geometry problem.  Rendering it below the canvas 
would effectively act as a image map, I guess, but maybe with more 
interaction possible?


> #2 could be addressed by extending SVG stroke and fill values to include
> arbitrary CSS image values, and using the element() image value to refer to
> a canvas. I think that feature would be useful in many ways, and I'd be
> interested in supporting it.

That's an interesting specific proposal, thanks.  We'll talk about that 
at the SVG F2F at the end of July.  If you have more details or have 
time to tinker around with that, I'm interested to hear more about it.


> I think #1 can be quite easily implemented as a JS library. I'm not
> convinced it would be necessary to provide direct browser support.

Yeah, I kinda did this already [1], and Charles and others have attacked 
it the reverse direction.  SVG needs a new API anyway, since as Tab 
mentioned, the DOM API is pretty lousy.  Having it as a script library 
doesn't solve the marshalling problem between script engines and the 
DOM, so it doesn't help SVG's performance (though that's not a Canvas 
problem).  If we could benefit from a new API anyway, why not kill two 
birds with one stone?

[1] http://schepers.cc/w3c/svg/api/cog.svg

Regards-
-Doug

Received on Tuesday, 12 July 2011 04:53:28 UTC