Re: agenda+ SVG 2 Features and Approach

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

Received on Sunday, 30 October 2011 17:46:38 UTC