Thread and GUI
Thread and GUI
Hi Bernd,
Is it normal that when I launch the "settings" window, it freezes temporarily the GUI below ?
For example, when the DJ PLAYER A is currently playing a track, with the vertical bar showing the current playback position, and when I launch the settings window, I could see, below, that the interface freeze during launching process. Once the settings window totally opened, the playback position keeps on moving...
Is there not any thread for GUI and another for the others tasks ?
Not very anoying, but it's only a question...
Regards,
--
Theo
Is it normal that when I launch the "settings" window, it freezes temporarily the GUI below ?
For example, when the DJ PLAYER A is currently playing a track, with the vertical bar showing the current playback position, and when I launch the settings window, I could see, below, that the interface freeze during launching process. Once the settings window totally opened, the playback position keeps on moving...
Is there not any thread for GUI and another for the others tasks ?
Not very anoying, but it's only a question...
Regards,
--
Theo
Theo, from France.
Re: Thread and GUI
Yes, unfortunately.
Every UI must run in its own thread - meaning it is independent from any other audio processing thread.
However, there is only one single UI thread available.
So if 'painting' of many elements (like in the general settings) is required, this might take some time.
The same happens, if a new WaveForm is being redrawn... but as all UI activity must and can only happen in this one and single UI thread, this means the other UI paintings/updates are blocked for that time.
But as said, this will never affect any audio processing or any other file operations tasks, which are always carried out in their own threads.
Therefor the UI thread runs at normal priority, whereas the audio threads run at highest priority.
Every UI must run in its own thread - meaning it is independent from any other audio processing thread.
However, there is only one single UI thread available.
So if 'painting' of many elements (like in the general settings) is required, this might take some time.
The same happens, if a new WaveForm is being redrawn... but as all UI activity must and can only happen in this one and single UI thread, this means the other UI paintings/updates are blocked for that time.
But as said, this will never affect any audio processing or any other file operations tasks, which are always carried out in their own threads.
Therefor the UI thread runs at normal priority, whereas the audio threads run at highest priority.
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
Re: Thread and GUI
Bernd, can this freezing or longer response be optimized somehow or does it only depend on each computer´s parameters and quality of graphic card? Or it does not have anything to do with graphic card?
Peter
Re: Thread and GUI
No, that is basically determined by the CPU speed and the speed of the grapgics card - but mostly by the speed (GHz) of the CPU.
How long is that on your machine and what machine are you using?
Here it is typically only 1 second.
How long is that on your machine and what machine are you using?
Here it is typically only 1 second.
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
Re: Thread and GUI
Please, see attached printscreen. It takes around 1-3 second depending on what is being processed in PF at the time when I open settings. This delays are also when minimizing and maximizing application to windows taskbar.
- Attachments
-
- Untitled.jpg (30.52 KiB) Viewed 9835 times
Peter
Re: Thread and GUI
Yes, as explained - that is normal!
Audio is not effected by this - so no problem at all I guess.
If you need that faster try out a 3.6GHz Quad-Core CPU...
Audio is not effected by this - so no problem at all I guess.
If you need that faster try out a 3.6GHz Quad-Core CPU...
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
Re: Thread and GUI
From my experience, there are cases when not only the UI is affected in the described cases. E.g., on track change during Auto Play, with players set to auto-load and auto-unload, the waveform for the newly loaded track is being drawn, and while doing so, the UI freezes. If I now activate TalkOver during this second or two to start speaking, then it is possible that the unmuting of the input channel is delayed and/or what gets put out from the input channel is garbled for a short time. I noticed this prominently when running PFOA on a Sempron 2800+ (2 GHz), but if I am ‘unfortunate’ enough in timing I can still reproduce it on this machine, powered by an AthlonII X2 255 (2× 3.1 GHz). In some cases it can even delay the start of a queued audio file when auto-playing.
So, in summary, it might not be possible to do several things at the same time when the UI is frozen due to some program activity.
Having said that, do you think it would be feasible to implement a setting to delay auto-loading (but not auto-unloading, as that shouldn’t consume a noticeable amount of resources) tracks by a defineable amount of time? I think a resolution down to 1/10 s would suffice for such a setting.
So, in summary, it might not be possible to do several things at the same time when the UI is frozen due to some program activity.
Having said that, do you think it would be feasible to implement a setting to delay auto-loading (but not auto-unloading, as that shouldn’t consume a noticeable amount of resources) tracks by a defineable amount of time? I think a resolution down to 1/10 s would suffice for such a setting.
Re: Thread and GUI
Thank you fgor the answers...
It seems other .NET software doesn't give the same symptom... Or perhaps you make too much controls before opening some windows (like the "settings" one) ? Optimization ?
Is it your choice ? or a technical constraints of .NET ?However, there is only one single UI thread available.
It seems other .NET software doesn't give the same symptom... Or perhaps you make too much controls before opening some windows (like the "settings" one) ? Optimization ?
Theo, from France.
Re: Thread and GUI
It's not a real problem (by the way, not for me). It's only GUI matter and, as you mentioned, in most cases, audio is not affected...
Theo, from France.