I work with a similar situation. We handle this by collecting the data
into a data structure and then plotting our data at whatever rate we can
support. This way you can plot all the points but there may be multiple
points added since the last time you drew the graph.
Steven Vahl wrote:
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: nanogui-unsubscr...@linuxhacker.org
For additional commands, e-mail: nanogui-h...@linuxhacker.org
