Re: 1.2 feedback: Streaming

From: "Thierry Kormann" <tkormann@ilog.fr>
> > There are many possible uses for streaming, e.g.:
> > * "movies" - this is probably the biggest area for Flash right
> > now. Could be
> > animated instructions, feature walk-throughs, intros and much more.
> > Streaming makes it possible to have a >100kb movie that still
> > plays without
> > a long waiting time. I think this is the most important case.
>
> A Jon said, I don't think this is the market place for SVG.

I think this is a huge market place. I don't know if I'm the typical user of
SVG/Flash, but this kind of productions (e.g. animated technical education,
illustration of products) are well more then 50% of my work.

> > * applications - load the initial user interface first, load in
> > functionality later
>
> Using the extensions getURL/parseXML, you can already do load-on-demande
> (custom or XML datas). Those methods are implemented in both ASV and Batik
> and should be in some way or another part of SVG1.2.

I sure don't think we should need scripting for loading regular content. If
so, why do we have a declerative syntax for SVG at all?

> > * level-of-detail images - such as maps.
>
> See previously. load-on-demand can already be done.
>
> To me, simple guidelines on how to author your SVG content such as the
> viewer can display things without having the whole document in memory is
> also a solution. I don't think (at this time) that we need to add anything
> in SVG apart from getURL/parseXML.

I don't think that scriping is a good solution for this. It makes a simple
(but big) movie really complex by having to modulize it into seperate
downloadable parts and only dynamic user agents will ever be able to support
"streaming". It also fits really bad into a automated workflow, for example:
you have technical data in some format (e.g. CAD), automatically convert
this to SVG (creates a 400 kb file). Now, this will take quite some time to
download and meanwhile the user will have zero feedback. Unless, by some
complex combination of server-side and client-side scripts we can split the
file into several (10 or so) smaller files that we can download
sequentially. This is not a good solution.

Would it be possible to build a SVG renderer that uses a SAX parser? If not,
how much would SVG need to change to allow for this?

Actually, SVG already should already support streaming since one of the
criteria on a "Conforming High-Quality Dynamic SVG Viewer" is: " Progressive
rendering and animation effects (i.e., the start of the document will start
appearing and animations will start running in parallel with downloading the
rest of the document)."
(http://www.w3.org/TR/SVG11/conform.html#ConformingSVGViewers) This sounds
like streaming to me. Is there any user agent that does this today? How is
this supposed to be done? I agree that simple guidelines would be perfect
for authors that already want to support streaming. It would probably also
be useful with some directions on how user agents are supposed to do this.
It would require using something like a SAX/pull parser I guess.

Of course, this is hard thing to solve. How would a Conforming High-Quality
Dynamic SVG Viewer handle this pretty hypothetical document :-)

<svg xmlns="http://www.w3.org/2000/svg" width="100%" height="100%">
 <rect width="100" height="100" id="theRect" />

 <!-- one million megagigabyte of SVG -->

 <animate xlink:href="#theRect" attributeType="CSS" attributeName="opacity"
from="1" to="0" dur="5s" repeatCount="indefinite" />
</svg>

/niklas

Received on Tuesday, 19 November 2002 07:36:50 UTC