- From: Charles Pritchard <chuck@jumis.com>
- Date: Sun, 30 Oct 2011 12:19:30 -0700
- To: Rick <graham.rick@gmail.com>
- Cc: "www-svg@w3.org" <www-svg@w3.org>
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 UTC