Re: hit testing and retained graphics

Am 11.07.11 21:52 schrieb "Doug Schepers" unter <schepers@w3.org>:

>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?

Love it! Whenever I hear "helps performance", I'm all in :) So basically,
you are thinking about a radical new API that moves off the DOM? As that
seems the only way to heavily increase SVG performance (correct me if I'm
wrong).

In my ideal world, I would love to see canvas.getContext("SVG") as a 2D
retained high level API, and then something like canvas.getContext("O3D")
as the counterpart, or any high level 3D retained API, to actually ease
development and improve performance. I'll be brainstorming about this
further. It's intriguing.

>
>[1] http://schepers.cc/w3c/svg/api/cog.svg
>
>Regards-
>-Doug
>

Received on Tuesday, 12 July 2011 14:37:54 UTC