PDA

View Full Version : Adding NDI support to WPF application



millst
12-09-2018, 04:22 PM
Hi

I have downloaded the SDK and have the sample WPF application running great in visual studio 2017 enterprise.

In my own app, I've added a ref to the dll and it all compiles fine.
If I add xmlns:NDI="clr-namespace:NewTek.NDI.WPF;assembly=NDIlibDotNet2" to my XAML. it all works fine as well.

However as soon as I add an NDI container, I start running into problems

<NDI:NdiSendContainer NdiWidth="1920" NdiHeight="1080" NdiName="Test" HorizontalAlignment="Stretch" VerticalAlignment="Stretch">
</NDI:NdiSendContainer>

The application compiles and runs fine and is sending NDI frames perfectly.
However, after around a minute, the application stops running all its internal timers, no errors and nothing reported in the output, it just stops working.
However it is still sending out NDI frames perfectly.

As soon as I remove the NDI container from the XAML, it goes back to working perfectly again.

Its a scoreboard application receiving weird pseudo XML over UDP from a non standard scoring system and it displays the data graphically.
Because the data is not XML compliant, I do have to do some weird parsing stuff and the app has a lot of timers.

Its C# 4.6.1.

Has anyone come across anything like this before?

jperbicella
12-10-2018, 07:40 AM
My first time experimenting with the SDK I used a lot of timers. I was using C# in winforms. After watching it lock up, I flipped to background workers to use separate threads....do you need to do something similar to multi-thread your app?

millst
12-10-2018, 03:08 PM
My first time experimenting with the SDK I used a lot of timers. I was using C# in winforms. After watching it lock up, I flipped to background workers to use separate threads....do you need to do something similar to multi-thread your app?

Perhaps that might be worth trying. I'm using dispatch timers at the moment for multi threading.
I have timers to process different metrics at different rates to reduce CPU load so that things like stopwatches update by the millisecond, but totals and summaries only update every second.

I've not used background workers before, I'll have to do some checking to make sure they can access the data tables I'm using to store the live data.

I wonder what the issue is with using Timers with the SDK?

jperbicella
12-11-2018, 09:57 AM
I wonder what the issue is with using Timers with the SDK?

This is an interesting point. My winform application was getting hung up on the fact I had it sending frames constantly (I was writing an application to send graphics and a text ticker), so naturally it wouldn't be able to send graphics while running other processes.

millst
12-11-2018, 02:37 PM
This is an interesting point. My winform application was getting hung up on the fact I had it sending frames constantly (I was writing an application to send graphics and a text ticker), so naturally it wouldn't be able to send graphics while running other processes.


I think I have almost the opposite problem, NDI is sending frames perfectly, not dropping any. Its just the timers are all stopping so none of the graphics are updating. However, animated components I have running are still running so I can see the NDI frames changing which indicates NDI is all good. As soon as I disable NDI, all the timers spark back into life. Its weird.

Antony Corbett
12-28-2018, 11:19 AM
Its just the timers are all stopping...

If they are DispatcherTimers then their operations are placed on the dispatcher queue so will be competing with the UI activity of the NDI SDK. You can increase the priority of the timers or perhaps better change to system timers and identify any code that must run in the UI thread and use the Application dispatcher to delegate it.