Yes, that's what David Dailey proposed.
InkML has some interesting semantics for trace and channel. They're unrelated but I think they're interesting.
On Oct 30, 2011, at 11:35 AM, Rick <graham.rick@gmail.com> wrote:
> Hello Group.
>
> Regarding replication.
>
> I haven't followed this closely pardon me if this is an old idea.
>
> Has anyone considered using SMIL semantics for replication? It occurs
> to me that such an approach could lead to some efficient code reuse
> and merge a learning curve.
>
> On Sun, Oct 30, 2011 at 1:46 PM, Charles Pritchard <chuck@jumis.com> wrote:
>> On 10/29/11 9:15 PM, Cameron McCormack wrote:
>>>
>>> Hi Charles.
>>>
>>> On 8/05/11 1:50 PM, Charles Pritchard wrote:
>>>>
>>>> The two areas most-lacking in SVG, the two reasons why I continue to
>>>> use a canvas back-end, when an SVG backend may be available, are
>>>> bitmap accumulation and n-dimensional trace groups.
>>>
>>> The SVG Working Group has been working through requirements for SVG2
>>> this week and when coming to this email
>>> http://lists.w3.org/Archives/Public/www-svg/2011May/0055.html it wasn't
>>> clear to us what you meant by the above. Would you be able to explain in
>>> more detail these two areas you feel are most lacking in SVG?
>>>
>>> Thanks,
>>>
>>> Cameron
>>> (ACTION-3156)
>>>
>>
>> TL;DR: The replicate proposal works fairly well for viewing an InkML
>> document. Enable-background, semantic zoom and other new CSS developments
>> may help to maintain performance within advanced scenes.
>>
>> ...
>>
>> The Replicate Proposal:
>> http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2010/replicate.htm
>>
>> Replicate supports pen effects:
>> http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2010/eisenberg1.svg
>>
>> In SVG 1.x, this requires a whole lot of extra DOM nodes.
>>
>> In one of my tests, it took 13 seconds, on an Apple iPhone (iOS 4.2) to
>> render a scene in SVG and less than a second to render the same scene in
>> Canvas. They were otherwise identical.
>>
>> In addition to taking too long to render: the scene was rather unstable in
>> the iPhone. The Canvas scene was rendered to a bitmap with a finite size,
>> and I could monitor events, such as resize, to decide when to repaint the
>> scene at a higher resolution. I was not able to "lock in" the SVG scene onto
>> a bitmap, and so resize and rotation events forced unneeded repaints.
>>
>> SVG has enable-background within the <filter> spec to setup various bitmap
>> semantics, but they're not widely implemented nor have I ever seen them use
>> to prevent repainting.
>>
>> SVG enable-background link:
>> http://www.w3.org/TR/SVG/filters.html#AccessingBackgroundImage
>>
>>
>> Microsoft's semantic zoom is something to keep an eye on.
>>
>> Semantic Zoom in CSS:
>> http://msdn.microsoft.com/en-us/library/windows/apps/hh465375(v=vs.85).aspx
>>
>> Though its focus is actually reordering content, similar CSS markup could be
>> used to signal repainting behavior in SVG. Without repainting, bitmap
>> semantics don't mean much. But, SVG is repainted, either through user
>> interaction, primarily zoom, or through animation. We need all the hints we
>> can provide to ensure that the user experience can be made smooth.
>>
>>
>>
>> ....
>>
>> InkML authoring is much easier support in Canvas than SVG.
>> Using SVG for custom fonts and ink support reminds me of the painful
>> experience I had with VML.
>>
>> There will be some discussion at TPAC about InkML:
>> http://lists.w3.org/Archives/Public/public-canvas-api/2011OctDec/0022.html
>>
>> An InkML rendering example written in JS and Canvas:
>> http://inkml.codeplex.com/
>>
>> Current InkML Spec:
>> http://www.w3.org/TR/InkML/
>>
>> Distinction between vector rendering of ink input and raster rendering:
>>
>> While SVG can be used to display path outlines it's not particularly easy
>> for authors to calculate them. lineTo is not attractive, markers are not
>> powerful enough.
>>
>> At it's most basic, I need to be able to take trace group with pen pressure
>> and use it.
>>
>> <trace>0 0 10 10 10 100</trace>
>> point at x:0,y:0, pressure 10%, point at x:10, y:10, 100%.
>>
>> With that, I know that I need to run a replicate from 0,0 to 10,10, and
>> apply scale (or opacity, or a combination) from 10% to 100%.
>>
>> David Dailey's replicate proposal can handle these semantics fairly well:
>> http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2010/replicate.htm
>>
>> It was not designed with InkML in mind: the proposal may benefit from
>> borrowing InkML trace groups and channel definitions.
>>
>> ....
>>
>> SVG was designed to run as pure markup. It works fairly well, but sometimes
>> this means suffering the same fate of VML. Mozilla has vetoed and renewed
>> their disapproval of SVG fonts. In most implementations displaying glyphs,
>> fonts are rendered to a temporary bitmap or a bitmap cache, before composite
>> operations. Though authors can try to use the <use> element, it's just not
>> the same.
>>
>> SVG is intended to run on a variety of devices. There are times when a user
>> on a low powered device wants to see a high quality scene. Making that scene
>> operate with minimal latency can be quite difficult. The more hints that
>> authors can provide to the rendering engine the better. Microsoft has
>> recently introduced contextual zoom as part of Metro. That's something to
>> look into.
>>
>> With Canvas, as it is low level, I'm able to support heuristics in my
>> application; with SVG, I'm at the mercy of the SVG implementer. If SVG had
>> additional semantics for handling bitmap buffers, I'd be able to use the
>> same tricks in my SVG DOM as I do with Canvas.
>>
>> I could setup font buffers, I could setup better repainting hints. I could
>> apply and cache filter effects.
>> For some of my uses, I need these items. And that's why I keep going back to
>> Canvas to implement them.
>>
>> I do use SVG to formalize these techniques, and for visual testing. Many of
>> those SVG docs are not practical for distribution to end-users. They're
>> simply too slow in current SVG implementations.
>>
>>
>> -Charles
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
> --
> Politicians should wear uniforms like Nascar drivers.
> Emblazoned with their corporate sponsors.