After the update where Threads could no longer access UI elements (Which really, that should be up to the developer) I tried to switch to Timers. It was never nearly as smooth as it was with threads so I went back to an older version.
Fast forward to this week. This time I decided to spend more time on the task at hand during the holiday week/end to finally get this handled… rewrote all of it… and despite it running beautifully on Win7/8… XP runs like junk.
My timers completely stop running in XP for no reason that I can narrow down. All of them. Why? The main thread is given plenty of processor time and they run fine for a little while.
Those of you who have made this switch… what’s the best strategy? Who’s run into this and how did you solve it?
Only move the code that updates UI to a timer. Leave your main processing in the thread. You should only update UI a couple times per second anyway or you’re wasting processing time.
The main processing is still in a single thread, which gives plenty of time to the main thread.
This is real-time vehicle data that needs more than a few updates per second to be useful to a tuner. That’s the whole point of the application, so that is where most of the processing time should be spent.
I think what Tim is saying is that the display should only need to update a few times a second… the data can update as it comes in or is generated. Maybe store the display data in an array or string, or create a picture that the thread updates, then the timer just draws it to screen. The timer mode can be used to initiate a redraw as soon as the thread has new data to display.
Please remember that timers are dependent of the main thread. If for some reason an event or something else holds the app, it stops the timers. As you mention the app works fine in Windows 7 and 8, it looks as an XP specific issue.
XP may not be as good as 7 and 8 at dealing with real time data processing. Drivers are not the same, usually. Maybe some of the operations in the thread tend to hold the main thread processing. Now it seems difficult to track. Maybe you could send signals from the thread with System.debuglog at the start of each heavy processing and the same from a timer, say, updating every second. You should be able to spot when the main thread gets frozen.
Yes, but in this scenario it does need to update UI more than a few times a second and actually comes in much faster than that (For recording, graphing the data, and export to CSV). The data needs to be displayed as real-time as possible, which worked great in the threaded version.
The redraw via thread with timer update is an interesting concept, but accessing the class causes the exception. This would need a complete rewrite of almost every class. Not sure I can try that for S&G.
The thread continues to run and process data even after the timers cease and is not tied to the main thread in any way other than booleans to let it know it should be handling certain tasks at any given time. The main thread is free and still able to click through other tasks, windows, etc with no lag whatsoever. Processor usage even drops to 0-1% depending on what I’m trying out at the time. Even when the thread is sleeping for 500ms at a time the timers still do not function. The main thread is doing nothing during that time. Talk about confusing. 13r2, here I come. Back to Xojo crashing every time the debugger comes up.
One thing I like to do is create a timer with a period of 20 (50fps) . The thread is free to update the data as needed and just calls
if displayTimer.mode=0 then displayTimer.mode=1
whenever there is new data.
Then the timer fires up to 50 times per second, but not more than needed, and renders the data without regard to what the thread is doing. Never had any trouble with that approach… and it’s very simple to implement.
[quote=107706:@Michel Bujardet]Granted, for graphs you need the kind of update a movie would require, at a minimum every 30th a second for a smooth effect.
Seems odd that the main thread remains responsive and timers get frozen.[/quote]
I know. Very odd! I can still open files and make changes. Save and load again to verify my changes.
[quote=107708:@jim mckay]One thing I like to do is create a timer with a period of 20 (50fps) . The thread is free to update the data as needed and just calls
if displayTimer.mode=0 then displayTimer.mode=1
whenever there is new data.
Then the timer fires up to 50 times per second, but not more than needed, and renders the data without regard to what the thread is doing. Never had any trouble with that approach… and it’s very simple to implement.[/quote]
I have tried similar, but I’ll give it another go.