AW: [cgmo-webcgm] Groups - WebCGM TC telecon minutes 20070620 (20070620_WebCGM_TC_Telecon_minutes.doc) uploaded

["Weidenbrueck, Dieter" <dweidenbrueck@ptc.com>]

Lofton,

DOM driven animation would not yield the required results.
To obtain a smooth animation you have to render at least 20 to
25 frames per second. IMO, this is very difficult using a JSCRIPT
on an HTML page making DOM calls.

I don't see the necessity of having a scripting language internal
to the CGM file. Declarations would be sufficient.

Anyway, this is not the point of discussion now. I support animation,
however, I warn other implementors that this will require
- a major rewrite of your rendering engine
- the introduction of timelines and time calculations
- fast and high quality rendering
- weird stuff if you want to support transparency during animation
- a whole lot of authoring functions to allow for creation
  of animation steps

Unless we see serious interest and commitment from other vendors,
we would suggest not to tackle this big animal. If others want to
jump in, we'd be happy to share our experiences and help to drive
this.

Regards,
Dieter

> -----Ursprüngliche Nachricht-----
> Von: Lofton Henderson [mailto:lofton@rockynet.com] 
> Gesendet: Donnerstag, 21. Juni 2007 23:23
> An: Bezaire, Benoit; cgmo-webcgm@lists.oasis-open.org
> Betreff: RE: [cgmo-webcgm] Groups - WebCGM TC telecon minutes 
> 20070620 (20070620_WebCGM_TC_Telecon_minutes.doc) uploaded
> 
> Hi Benoit,
> 
> Good analysis.  One comment, seeking clarification (perhaps I 
> caused some confusion)...
> 
> At 04:27 PM 6/21/2007 -0400, Bezaire, Benoit wrote:
> >Hi All,
> >
> >I missed the last part of the telecon (animation topic)...
> >
> >In my opinion, the use case presented to us, would be best 
> solved using 
> >declarative animation.
> 
> In telecon used "declarative animation" as being defined by 
> declarative language within the graphics file, SVG-like.  
> Implicitly, I distinguished it from DOM animation, where a 
> script could drive the manipulations of properties through 
> the DOM.  (And distinguished both from GIF-like "visibility 
> animation".)
> 
> The two could give very similar results, in some cases.  
> Right now a DOM script could manipulate any of the Style 
> Properties [1] and achieve a SVG-like result.  So you could 
> cause the text size of some (object) string to swell and 
> shrink.  Or the color to mutate.
> 
> [1]
> http://www.w3.org/TR/2007/REC-webcgm20-20070130/WebCGM20-DOM.h
> tml#styleprop-table
> 
> If there were a new "transform" style property (or APS 
> attribute), you could do even more.  Etc...etc... E.g., if 
> you could treat the Fill Reference Point as a style property, 
> then you could achieve the illusion of flow in a pipe.  
> (Where the pipe contents is indicated by a pattern like "/  /  /..."
> 
> So in theory, DOM animation could give results similar to 
> SVG-like declarative animation, and in any case, very much 
> better than GIF-like animation.
> 
> There are issues with DOM approach, not the least of which are:
> 
> -- authoring: a content author who wants animation must 
> produce a DOM script along with the original static picture;
> 
> -- performance: if the implementation knows that it is 
> dealing with in-graphic declarative animation, it can 
> optimize to ensure adequate performance.  With DOM animation, 
> would adequate performance be problematic? (I don't know ... 
> I'm asking the question.)
> 
> The biggest advantage of DOM animation is obvious -- we don't 
> have to invent and impose an intra-WebCGM animation language.
> 
> A couple more comments...
> 
> >Things like fluid levels and water flow can't really be 
> addressed with 
> >an animated gif or visibility animation. It just wouldn't look very 
> >good. Or if it did look decent; it would require a lot of 
> work from a 
> >user perspective (probably too much to be acceptable).
> 
> Right ... animated GIF is extremely limited, DOM animation is 
> less so but still somewhat, and both are shifting burden to 
> the authoring side, from the viewing side.
> 
> 
> >There are four main classes of animation:
> >i) transforms: rotate, scale, translate, skew.
> >ii) colors: fill, stroke etc...
> >iii) motion along a path (somewhat similar to a translation).
> >iv) point animation, ex: adjusting the 'length' of a 
> rectangle, two of 
> >the four corners (i.e., points) move over time.
> >
> >This a lot of work and would require a very serious 
> commitment from all 
> >implementers.
> 
> Indeed.  I'm unsure how implementers feel about implementing 
> a chunk of SVG-like declarative animation language.
> 
> On the other hand, what are the tech-pubs requirements, and 
> how much of them (if any) could be met in a short-term 
> approach with a couple new properties and DOM animation?  
> (You implementors probably have some sense of this.)
> 
> Regards,
> -Lofton.
> 
> 
> 
> 
> >-----Original Message-----
> >From: david.w.cruikshank@boeing.com
> >[mailto:david.w.cruikshank@boeing.com]
> >Sent: Thursday, June 21, 2007 4:02 PM
> >To: cgmo-webcgm@lists.oasis-open.org
> >Subject: [cgmo-webcgm] Groups - WebCGM TC telecon minutes 20070620
> >(20070620_WebCGM_TC_Telecon_minutes.doc) uploaded
> >
> >The document named WebCGM TC telecon minutes 20070620
> >(20070620_WebCGM_TC_Telecon_minutes.doc) has been submitted by Mr. 
> >david cruikshank to the OASIS CGM Open WebCGM TC document repository.
> >
> >Document Description:
> >Minutes of telecon
> >
> >View Document Details:
> >http://www.oasis-open.org/apps/org/workgroup/cgmo-webcgm/docu
> ment.php?d
> >o
> >cument_id=24466
> >
> >Download Document:
> >http://www.oasis-open.org/apps/org/workgroup/cgmo-webcgm/down
> load.php/2
> >4 466/20070620_WebCGM_TC_Telecon_minutes.doc
> >
> >
> >PLEASE NOTE:  If the above links do not work for you, your email 
> >application may be breaking the link into two pieces.  You 
> may be able 
> >to copy and paste the entire link address into the address field of 
> >your web browser.
> >
> >-OASIS Open Administration
> 
>