Hello, I wanted to say thanks to everyone for taking the time to help me with my problem. I thought I'd let you know how it worked out, in case you're interested. (If you're not, feel free to skip all the following...)
To clarify my situation, I was already collecting the data in a different process than the GUI process. In my GUI, based on Mr. Grier's suggestion, I first I tried the GrFlush() command after my GrPoly() command. By itself, the GrFlush() did not help things much. But, by trial and error when I was debugging, I found that when I called a GrGetGCTextSize() command after the GrFlush(), then the problem with my GUI process "locking up" (not getting any processor time) went away. I had no idea why this worked until Mr. Haerr mentioned the need to call a Gr operation that requires a client read. I must have stumbled upon this by accident. So far I haven't noticed any problems caused by calling GrFlush() after every GrPoly(). In parallel to this, Mr. Santini was trying to help me to squeeze a little more performance out of my system by using the LINK_APP_INTO_SERVER option to eliminate the separate nano-X server process. Unfortunately, I don't know much about Makefiles and I haven't been able to figure out how to modify the Makefile I'm using to properly link all the required nano-X libraries to get my application to build when this option is enabled. Since I'm not expecting a really big performance boost from this, and since most of my problems went away (for now) by adding the GrFlush() and GrGetGCTextSize() commands, I'll be leaving things as they are for now. I expect to revisit this performance issue later in my project when my real hardware platform is further along. (Right now I'm working on a development board.) Anyway, thank you all again. Steven V. -----Original Message----- From: Greg Haerr [mailto:g...@censoft.com] Sent: Wednesday, November 11, 2009 3:21 PM To: Klatt Uwe; Steven Vahl; nanogui@linuxhacker.org Subject: Re: [nanogui] AW: Overloading the nano-X server > I would try to collect the data in an additional thread. > The drawing can be done later with the normal gui thread. If this method were used to collect data, and GrFlush(), follwed by a Gr operation requiring a client read (like GrGetWindowInfo) were done in the gui thread, then the ratio of time spent collect versus plotting might be roughly approximated. This could then be used to schedule how much data was sent to the server. It could then be optimized be sending more graphics commands per collect/GrFlush() cycle, and elimnating the read operation, in the event it was more important to stay with the most recently collected data. Regards, Greg ====================== 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 V. 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
