|davi...@boeing.com||Jun 21, 2007 1:01 pm|
|Bezaire, Benoit||Jun 21, 2007 1:28 pm|
|Weidenbrueck, Dieter||Jun 21, 2007 1:50 pm|
|Lofton Henderson||Jun 21, 2007 2:22 pm|
|Weidenbrueck, Dieter||Jun 21, 2007 2:47 pm|
|Lofton Henderson||Jun 21, 2007 4:39 pm|
|Lofton Henderson||Jun 21, 2007 4:45 pm|
|Ulrich Laesche||Jun 22, 2007 1:19 am|
|Lofton Henderson||Jan 14, 2008 4:34 pm|
|Lofton Henderson||Jan 16, 2008 10:15 am|
|Subject:||AW: [cgmo-webcgm] Groups - WebCGM TC telecon minutes 20070620 (20070620_WebCGM_TC_Telecon_minutes.doc) uploaded|
|From:||Weidenbrueck, Dieter (dwei...@ptc.com)|
|Date:||Jun 21, 2007 2:47:04 pm|
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.
-----Ursprüngliche Nachricht----- Von: Lofton Henderson [mailto:lof...@rockynet.com] Gesendet: Donnerstag, 21. Juni 2007 23:23 An: Bezaire, Benoit; cgmo...@lists.oasis-open.org Betreff: RE: [cgmo-webcgm] Groups - WebCGM TC telecon minutes 20070620 (20070620_WebCGM_TC_Telecon_minutes.doc) uploaded
Good analysis. One comment, seeking clarification (perhaps I caused some confusion)...
At 04:27 PM 6/21/2007 -0400, Bezaire, Benoit wrote:
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  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.
 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.)
-----Original Message----- From: davi...@boeing.com [mailto:davi...@boeing.com] Sent: Thursday, June 21, 2007 4:02 PM To: cgmo...@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