Re: agenda+ SVG 2 Features and Approach

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.

Received on Sunday, 30 October 2011 18:36:08 UTC