in reply to Re^2: 2d animation
in thread 2d animation
Hm. OKay, but still at somepoint, someone is going to watch these movies right?
Drawing, compressing, shipping and displaying 60 frames a second of video in order to display 60 individual numeric values per second is a laborious, time & space consuming way of allowing them to see it. Especially if there are going to be many such videos.
It would be far more cost effective to construct a simple application that reads the raw timestamp/value pairs from a file and draws the scrolling line trace on the users screen on demand. Then you give the user(s) the application once and send them the raw data files -- which will compress readily -- as they become available.
My estimate is that 10 minutes of raw data -- say 2 x 64-bit float values per reading -- 16 * 60 * 60 * 10 = 1/2 Mb uncompressed and reasonably, less than half that zipped.
The same information captured as 640x480 video will run to ~60MB. Even if you radically compress it with a lossy codec, you'll be very lucky to get much below 30-35MB. And the results would be hideously blurry, blocky and inaccurate. Effectively useless for anything other than "Ooh. Look at that!".
I also seriously doubt that you'll be able to render the movies in real-time, which means you'll first have to record the data, and then play it back -- via some application that renders the scroll line trace -- so you can record that as the movie.
So, you'll need a line tracer anyway to create the movies. Once you have that, why not just give a copy to the user(s) and let them see the actual trace rather than wait for you to produce and ship some huge, blotchy movie of it?