[svg-developers] Re: SVG 1.2 feedback: SVGTimer Inteface - does this add anything?

2004-11-04 Thread Alexander Adam
hi, > but it presumably does that with a busy wait? seen as generally ecmascript > is run in the UI thread, you get the lovely "locking up" effect of the > browser. Right and that'd be somehow kill the SVG-Animation-Interactivity Format, wouldn't it? ;-) (Needless to say that Svg needs mo

[svg-developers] Re: SVG 1.2 feedback: SVGTimer Inteface - does this add anything?

2004-11-04 Thread Alexander Adam
Doug, > You comment about native time functions made me think that a viewer having > its own timer functionality will help with consistent timeline control, as > described in: > > 13.5 Time Manipulation > http://www.w3.org/TR/SVG12/animation.html#timemanipulation > > The new 'speed' attribut

RE: [svg-developers] Re: SVG 1.2 feedback: SVGTimer Inteface - does this add anything?

2004-11-03 Thread Doug Schepers
Hi, Alexander- Thanks for your comment. It's always interesting to hear from viewer implementors. You comment about native time functions made me think that a viewer having its own timer functionality will help with consistent timeline control, as described in: 13.5 Time Manipulation http://www

[svg-developers] Re: SVG 1.2 feedback: SVGTimer Inteface - does this add anything?

2004-11-03 Thread Alexander Adam
Ronan, > Good point about performance. > > But dont you think that asking each browser implementer to do this is a bit of > overkill? Granted, it takes the technical requirements out of the developers > and puts them in the hands of the infrastructure (viewer) people. But man, at > what

Re: [svg-developers] Re: SVG 1.2 feedback: SVGTimer Inteface - does this add anything?

2004-11-03 Thread Ronan Oger
On Tuesday 02 November 2004 16.21, Alexander Adam wrote: > >Ronan, > >> I am confused why this is necessary. Is this functionality not >basic to >> all scripting languages? Is the desire to provide a common API so >the >> naming convention is scripting-language independant? > >Well, a few builti

Re: [svg-developers] Re: SVG 1.2 feedback: SVGTimer Inteface - does this add anything?

2004-11-03 Thread Ronan Oger
On Tuesday 02 November 2004 16.41, Jim Ley wrote: > ><[EMAIL PROTECTED]> wrote in message >news:[EMAIL PROTECTED] >> SVG 1.2 Appendix B.1: SVGTimer Inteface >> >> I am trying to find new functionality that this requirement adds, and I >> see none. From what I see, it requires scripting, and the m

[svg-developers] Re: SVG 1.2 feedback: SVGTimer Inteface - does this add anything?

2004-11-02 Thread Jim Ley
<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > SVG 1.2 Appendix B.1: SVGTimer Inteface > > I am trying to find new functionality that this requirement adds, and I > see none. From what I see, it requires scripting, and the major scripting > languages all have support for some thin

[svg-developers] Re: SVG 1.2 feedback: SVGTimer Inteface - does this add anything?

2004-11-02 Thread Jan-Klaas Kollhof
It is a "replacement" for setTimeout and setInterval. Jan PS: setTimeout, setInterval, ... where never in the specs so they defined interfaces that can handle the functionality. e.g. getURL/postURL now in the specs as URLRequest Yahoo! Groups Sponsor --

[svg-developers] Re: SVG 1.2 feedback: SVGTimer Inteface - does this add anything?

2004-11-02 Thread Alexander Adam
Ronan, > I am confused why this is necessary. Is this functionality not basic to > all scripting languages? Is the desire to provide a common API so the > naming convention is scripting-language independant? Well, a few builtin apis are making sense due the fact that viewers may take advanta