W3C home > Mailing lists > Public > www-svg@w3.org > October 2011

Re: agenda+ SVG 2 Features and Approach

From: Charles Pritchard <chuck@jumis.com>
Date: Sun, 30 Oct 2011 12:19:30 -0700
Message-Id: <949F932E-5CD7-48E6-BCEB-8642DF2798D3@jumis.com>
Cc: "www-svg@w3.org" <www-svg@w3.org>
To: Rick <graham.rick@gmail.com>
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.
Received on Sunday, 30 October 2011 19:20:00 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:49 GMT