Continuously updating view - Custom Stream or Events?

Doing some initial research on a new project and one of my requirements is to implement a 3D display that will render a set of data that is updating at a frequency between 20ms - 500ms. So every (using the lower limit) 20ms new data will be available from an external resource (specialty hardware) and this data needs to be provided to the 3d view and rendered ASAP. For the sake of this question, you can think of the analogy of a weather station sampling data every 20ms and the requirement to push that data to a consuming service or object. Except for this example the weather station is connected to the consuming application so no need for networking, etc.

I'm a hack desktop developer, mostly just writing apps for my own manufacturing business, rarely enjoying the luxury of learning the underlying technologies that I take for granted with .net So with that disclaimer in place let me explain what I'm pondering: I originally thought I could just use a delegate and fire off events from the hardware component each time a new data set was ready. This is easy enough and ~50 method calls a second doesn't seem TOO abusive! ;0)

But then I thought, "hey, maybe I should use a stream for this!" and then quickly realized I don't unde开发者_开发知识库rstand Streams enough to know if this is a good idea or not. Based on what I have read and my experience with Streams working with files, HttpRequests, etc. it seems like it may be a good option to move data from one sub-system to another at a high frequency. Conceptually I picture the hardware component (the object interfacing with the hardware) writing to the stream each time it finishes acquiring a new set of data, then my 3D view would be reading from this stream and rendering it.

I have questions though:

1. This is basic, but I don't understand how the code reading from the stream knows when there is new data to be read. For example, if a new data set is written to the stream i a separate thread (of course) how would the "reader" know when that data was available?
2. Does the serialization and deserialization of my "MeasurementDataReading" object wipe out the performance gains from using a Stream rather than a delegate approach?
3. Am I completely misunderstanding the intent of Streams? I realize that it is not one continuous "stream" of data I'm working with, bur rather many small pieces with delays between.

I would suggest against a stream (at least directly) in this sort of scenario as it sounds like:

• the data your receieving will refreshing at a different rate than your display and...

• you're after a (near) real time display of what's happening now rather than a replay of previous events at a speed dictated by how fast your display refresh is

As a first pass, I'd suggest having a hardware data reading process continously update a single local data model and your display code read from that model upon each refresh of the display.

This sort of scenario isn't that far removed from the sort of issues that game developers face so you might want to sneak a peak at (or even implement it in) XNA and see some common ways to tackle these sort of issues.

Streams are typically used when you need to read a large chunk of data, but you don't want to have the whole chunk live in memory. The communication is one-way where a caller asks for data in sequential order. They aren't typically used to communicate updates from one entity to another.

I would recommend using an event on your entity that is changing and having your view subscribe to that event.