Quinn-Curtis Forums
Quinn-Curtis Forums
Home | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Tools for Microsoft .Net
 Real-Time Graphics Tools for .Net (VB and C#)
 Performance considerations.

Note: You must be registered in order to post a reply.
To register, click here. Registration is FREE!

Screensize:
UserName:
Password:
Format Mode:
Format: BoldItalicizedUnderlineStrikethrough Align LeftCenteredAlign Right Horizontal Rule Insert HyperlinkInsert EmailInsert Image Insert CodeInsert QuoteInsert List
   
Message:

* HTML is OFF
* Forum Code is ON
Smilies
Smile [:)] Big Smile [:D] Cool [8D] Blush [:I]
Tongue [:P] Evil [):] Wink [;)] Clown [:o)]
Black Eye [B)] Eight Ball [8] Frown [:(] Shy [8)]
Shocked [:0] Angry [:(!] Dead [xx(] Sleepy [|)]
Kisses [:X] Approve [^] Disapprove [V] Question [?]

 
   

T O P I C    R E V I E W
LarsOo Posted - 02 May 2006 : 10:34:25
I'm looking for a RT graphic library for .NET and since our company has used QC products before I downloaded the demo and run a couple of example projects (RTXYPlot and Polygraph).

In the Polygraph example I set the timer1 interval to 100 ms. This makes the cpu usage go up to 100%. Is the demo 'not complete' or is this the kind of performance I can expect to get when using QC RT for .NET? Or are there posibilities to optimize the examples to get better performance?
1   L A T E S T    R E P L I E S    (Newest First)
quinncurtis Posted - 02 May 2006 : 11:29:14
The Real-Time Graphics Tools for .Net (and Java) products use a different update algorithm than our earlier Windows and DOS products. We no longer update graphs incrementally each time a change is made to the data. The inremental update method always caused problems with other graphical objects in the same plotting area as the scrolling graph objects. Also, we found that if text objects were included in the update, update rates were drastically reduced.

In the .Net product, the data is updated asynchronously with with display. In theory you can update the data 1M updates/second, while only updating the display once a second. We feel that in the long run, this is a superior update technique, because it makes no sense to update the display faster than the eye can follow (20-30 times a second), but actual data update rates can be orders of magnitude faster.

This means though, that until computers get fast enough to maintain an optimal display update rate for a given application, some applicaitons will run much slower than the equivalent incremental update method. This is what you are seeing in the examples you site. That is the tradeoff we made in the software in order for our software to perform optimally on the next generation of computers.


Quinn-Curtis Forums © 2000-2018 Quinn-Curtis, Inc. Go To Top Of Page
Powered By: Snitz Forums 2000 Version 3.4.07