Guys... Don't push your SVG update rates too high. In my opinion there is nothing to be gained in going past 20Hz (20 updates/second), and plenty to be gained from staying below 10Hz (10 per second).
No matter what you intend to do, you need to allow for the transport layer. A 100-Hz update rate is meaningless if you have a 100ms lag When you do traceroute tests, you will see that the delays you can expect on the internet are 0.3 seconds for round-tripping.... With that kind of performance, you are seriously wasting your time if you are sampling at 10x or 20x your lag... Might as well go with 5-20Hz.... That's the best you can expect to need if you use tcp systems. A comparison that may be useful to you guys... I've been doing a lot of monitoring systems work using the Micromuse Netcool messaging infrastructure. For larger applications, you end up needing to send your signals to a concentrator of some kind, even if it is to allow for scalability and auditing purposes... With Netcool, we find ourselves working with a 2-second lag due to the 2-step forwarding (alert event->central bus, bus->monitoring client). The point in the end is that you will be hard pressed, in my opinion, to require anything like 100Hz update rates. Finally, consider the scanning rate of your monitor. There is no point in doubling the scanning rate of your monitor, and even the best PC struggles to get past 100Hz updates. While it's true that instrumentation sampling rates may have high speed requirements for such things as closed-loop control, human beings are far slower with this stuff, and there are plenty of reasons why there is no need to go past 20-Hz when showing input to the user. I propose to you that the key performance criteria in all of our real-time GUI tools is not refresh rate but transmission speed. Ronan On Tuesday 11 January 2005 12:08, Rick Bullotta wrote: > I think the "bottom line" is that a solution involving ASV, inside a > browser, with a real-time 100Hz update, is highly unlikely, but custom > solutions using Batik, SharpVectorGraphics, or Mobiform may be possible. > > ---- [email protected] wrote: > > Hi, > > > > > You could probably feed that with a streaming feed over a socket, > > > but to the best of my knowledge there is no way to do this in > > > JavaScript. > > > > In Batik it works just fine. I have partially impl. the SVG1.2 Sockets > > using JavaScript in Batik. > > > > see http://jan.kollhof.net/projects/svg/playground/ > > or the SVG IRC client here: > > http://jan.kollhof.net/projects/svg/examples/index.xhtml > > they only work in Batik. > > > > > > > > > > Jan > > > > > > > > > > > > ----- > > To unsubscribe send a message to: > > [EMAIL PROTECTED] -or- > > visit http://groups.yahoo.com/group/svg-developers and click "edit my > > membership" ---- > > Yahoo! Groups Links > > ----- > To unsubscribe send a message to: > [EMAIL PROTECTED] -or- > visit http://groups.yahoo.com/group/svg-developers and click "edit my > membership" ---- > Yahoo! Groups Links > > > -- "Nice boy, but about as sharp as a sack of wet mice." -- Foghorn Leghorn --> contact me: ronan at roasp dot com ----- To unsubscribe send a message to: [EMAIL PROTECTED] -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" ---- Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
