What can I do to improve VB.NET gauge performance?

[dx0ddyu]

I've made a user control that represents the gauge I'd like to use. When I make, say, 10 instances of this control and attempt to update them every .4 seconds then systems.windows.forms.ni.dll uses 94% of my computer's CPU and only the form that has focus will actually update. If you prefer, it's steema.teechart.styles.cframe.draw sucking up 78%. Or, just below that, steema.teechart.drawing.graphics3dgdiplus.polygon with 47% and thus system.drawing.ni.dll 45%. Ahem!

So, as we covered last year, I'm doing AfterDrawValues, BeforeDrawHand and BeforeDrawValues.
AfterDrawValues: get the font, make and measure a string of the gauge value then resize and place accordingly
BeforeDrawHand: draw the target (as per http://www.teechart.net/support/viewtop ... 82&p=73820)
BeforeDrawValues: draw the red/green limit lines

Setting the needle value does a chart.invalidate and, again, this happens every .4 seconds.

So, anyway... Have any quick hints on speeding things up? Like, a lot, please. No, really, a lot a lot

Thx!

[dx0ddyu]

(And... I'd rather not post my code, actually. As I'm perusing the forum right now I see that GoogleBot is as well. Sigh...)

[dx0ddyu]

How do we set up double/triple buffering? Any benefit to doing so?

Or, can I push the processing of each gauge to a different thread (nope!)? To the video card?

Assuming I'm showing 2 copies of each gauge (that's just life) can I do magic and draw each just once but show it twice (albeit, alas, at different sizes and with different transparencies)? (And just think of how exciting and complicated the code would be. Great.)

[Christopher]

Hello,

It would be extremely useful if you could produce a Minimal, Complete, and Verifiable example (as explained here) detailing the context in which you experience sub-optimal performance. Which version of TeeChart.dll are you using? If you don't want to post code to these forums, please create a small project, zip it up and post it to our upload page here:

http://steema.net/upload/

[dx0ddyu]

Thx. I'll upload something I suppose

My feeling right this second is that implementing this (fully) in WPF will probably help. Kind of a bummer, really, since it already all exists. Hopefully that will render using the video card and not the CPU. I guess I'll do a few tests to make sure things work right before I go too crazy!


LOL. There's your example. "New Folder.zip". I hope it's minimal, complete and reproducible Seems to be all of those things.

[Christopher]

Hello,

thank you for your example project. I have run this project and profiled the TeeChart.dll, the Windows Forms component, with these results:

devenv_2018-02-28_11-08-47.png (35.97 KiB) Viewed 24097 times

looking more carefully at the functions I see this:

devenv_2018-02-28_11-13-59.png (66.18 KiB) Viewed 24097 times

I see these results as expected. What these results state is that nearly three-quarters of the time needed for TeeChart to render is used by System.Drawing.dll, a .NET Framework assembly. Just over a quarter of the time needed to render TeeChart is used by functions written by Steema within the TeeChart code. This is expected because TeeChart is a visual component and as such is completely dependent on the bitmap rendering algorithms of the .NET Framework.

Basically, then, the less that is drawn onto the TeeChart the quicker it will render. One example of this is the CFrame you mention, which can be made invisible (and hence not drawn) with code such as the following:

devenv_2018-02-28_11-21-17.png (21.17 KiB) Viewed 24097 times

the results of which look like this:

devenv_2018-02-28_11-20-08.png (82.82 KiB) Viewed 24097 times

I very much doubt that the TeeChart.WPF.dll will be quicker at rendering than the TeeChart.dll. Again, this is a question of the speed of rendering of the underlying .NET Framework code. The Windows Presentation Framework code for bitmap rendering is notoriously slow, we have had clients that have abandoned WPF completely becuase of this issue.

[dx0ddyu]

Well, in theory the .NET WPF is rendering using DirectX, no? And this is, in fact, born out by that project. If you close the Forms window and open several more WPF windows and then do the performance profiling again you will see radically different results. The WPF forms render much faster.

Still, the performance on all of them is really quite bad. I fully expect my customers to have 8-12 dials open at any given time. The performance issue renders the dials quite useless - these are real-time measures of processes and if the dial isn't updating then they do not know what they're doing.

As for the CPU graph in re: performance.... Mine shows that, too. However, that's as a percentage of total CPU on the computer. One core is railed. Given that graphics can only be done on one core this makes sense.



Edit: So... Do you have any other suggestions on performance? Taking the frame away makes things incredibly fast but visually things are a bit, um. How can I still have a full circle every time?

[dx0ddyu]

Looks like gauge.Frame.circled is really bad on performance and it doesn't appear to affect the end visual result - in this case.

[dx0ddyu]

Although, hey, that doesn't help things work.

So, a full circle dial does work but they don't with limit stops? That doesn't really make sense to me. Ah well.

[dx0ddyu]

So I have to ship. So what I did was to make the background of the Tchart a dark color and then I hide the frame. This is suboptimal but, hey, well, it does work, I suppose. And it performs.

[Christopher]

Hello,

I've created a little WPF project for you showing the effect of drawing ever less elements onto the Chart:
http://teechart.net/files/public/suppor ... ProWPF.zip

here, in Release mode, the project runs like this:

2018-03-01_10-42-53.gif (1.12 MiB) Viewed 24079 times

Again, I see this performance as expected - the fewer the elements, and the lesser the rendering complexity of each element (e.g. Gradient etc.), the quicker the chart paints. Please bear in mind that in WPF the frames per second is not an accurate reflection of the number of bitmaps the WPF framework renders to the screen - we calculate the FPS by the number of parses made through the TeeChart drawing code, but as WPF uses a retained mode graphics system then this is not an accurate reflected of the actual framerate.

[dx0ddyu]

Thanks Christopher. We'll keep these things in mind as we go forwards.