Main Site Documentation

Slow GUI Interface with Dispatcher Timer


#1

I am working with a data logging application. I am using GHI FEZ Cobra 1.3 for development.

My basic task is to polling and logging sensor data at every one minute. To achieve this I have defined a dispatcher timer with 1 minute interval in program.cs. During this timer interval, I do data acquisition, data validation and data storage in SD card. I also have other GUI classes which represents data and used for other configuration.

My problem is, whenever the dispatcher timer is executing the GUI interface responding slow. Except that it is responding properly.

Normally in .NET Framework C#, we are using Application.DoEvents(), Is there anything similar available over here for solution? Or please suggest another solution for the problem.


#2

Not that I can help but, I’m interested in your datalogger. Would you mind sharing your code?

Greetings,
Eric


#3

I suggest you define a timer that will handle all data acquisition, validation and storage. You don’t have to involve the main thread to do this. After you collect and verify your data you can updated your screen (this is where you use the Dispatcher). This way the GUI will be responsive at all times except those few ms when it gets updated.


#4

In my screen(GUI) class there is a dispatcher timer which is responsible for data representation.

I have multiple GUI classes which are responsible to show different tasks. I can not use the main timer (responsible for data acquisition, validation and storage) in the GUI class as i want to perfom it independantly from GUI classs.


#5

Look for System.Threading.Timer or .Thread


#6

Sorry for the delay in reply. I have tried with Timer and .Thread but didn’t get reply any method equivalent to “DoEvents”.

Any other options?


#7

Try Thread.Sleep(0) or Thread.Sleep(1) for a ~DoEvents() like behavior (not inside your UI thread - only worker thread(s)).

This will block the current thread, which should allow the scheduler to switch threads (e.g. to your UI thread if it is the only other thread on the scheduler). I say “should” because don’t have finer details of NETMF, but the idea would work in Big.Net and should work here. However only do that when you really want UI to do something and you know the UI thread is not blocking on something else. For example, you don’t want to block current work and do a context switch to UI that is already blocking on some IO as perf would then be worse from needless blocking and context switching tax. If UI is not doing any other IO, then should be ok. Also note, the scheduler will do this for you after 20ms to round robin ready threads.

This is almost the reverse of DoEvents. DoEvents is called “inside” the UI thread to allow other UI messages to get time (i.e. other events to run). The Sleep above is basically stopping one task to allow the UI thread more time to work (i.e. giving up balance of your current time slice).

Also, I have not experimented with thread priorities in netmf yet. But that is something else you may try in hopes to remove the hacky Thread.Sleep code above. Not sure if or how well it may help, but experiment a bit and let us know. On your worker thread, try something like:
Thread t = new Thread(…);
t.Priority = ThreadPriority.BelowNormal;