nanogui: Overloading the nano-X server
Subject:
Overloading the nano-X server
From:
Steven Vahl ####@####.####
Date:
9 Nov 2009 23:59:40 -0000
Message-Id: <9F69FF8A3F0CF8449F231D4324DB1B3A191D4A7886@EX1.asdi.com>
Hello,
I have a situation where a scientific instrument is capable of generating a new dataset as fast as every 10 milliseconds (although not always that fast), and my Nano-X code has to create an XY plot (graph) of the data and display it on a 320 x 240 display. I do not need to display every dataset the instrument generates (i.e. it is OK if some of the datasets are "dropped"), but I want the system to display as many as it can, up to the limitations of the processor and display hardware.
Currently, the way my code works is my Nano-X client uses the dataset from the instrument to calculate one GR_POINT for each pixel along the x-axis of the plot window. Then I call the "GrPoly" function, passing in that array of GR_POINTs, to "connect the dots" and create the plot on the screen.
This method works great until I set the instrument to the faster speeds. Then the Nano-X client starts sending the server "GrPoly" commands faster than the server can process them and the display can display them. The Nano-X server starts to fall behind, the "GrPoly" commands start stacking up in the queue, and the system becomes unresponsive because the nano-X server is working so hard and the client rarely is getting any time to run. (If I use the "GrPoints" function instead of "GrPoly", the system can keep up much better, but the plots don't look good enough.)
I am relatively new to Nano-X development, so I am hoping someone can help me with a solution to this.
* Is there a way for the client to find out somehow if the server is still working on a previous GrPoly command? If so, then the client could just "drop" any datasets that come in until the server and display had completed the one they were working on, preventing the server from becoming overloaded.
* Is there some other approach I could use to plot the data that would be faster?
Thanks for any ideas or suggestions.
Steven Vahl
________________________________
NOTICE: This message (with any attachments) is confidential and may constitute privileged communication, and is intended only for the recipient(s) named herein. If you are not the intended recipient, or a person responsible for delivering this message to the intended recipient, you are hereby notified that any distribution, copying or dissemination of the information herein is strictly prohibited. If you have received this e-mail in error, please contact us immediately by telephone, facsimile, or email, and delete this e-mail from your computer system without retaining a copy.
