UI Thread problem

I have an MFC dialog based application that shows the spectrum analyser of a sound file. The spectrum analyser is made of a CStatic derived class and is drawn on to using the GDI. I started using a timer to update my spectrum analyser drawing every 1 millisecond.

Everything was working properly, but I noticed that any 'for loops' that I run in my main application interupted my spectrum analyser drawing. So instead of using a timer to keep updating the drawing of my spectrum analyser I did it in a user interface thread.

So from my UI thread I call like this to update the drawing in my CStatic derived class:

Code:

---

do
{
//m_SpectrumDisplay is my CSpectrumDisplay(Derived from
//CStatic) variable on my main dialog.
  m_pMainDlg->m_SpectrumDisplay.DrawSpectrum(m_pMainDlg->spec_scaled_fft);
       
}while(!bTerminated);

---

This made the interuptions not as bad, but the drawing still gets interupted a little bit when running for loops in the main dialog. I thought that if I was calling the drawing function in my CStatic derived class from a UI thread that it would not be bothered by the main application. Is this not the case?

Do I have to somehow make my whole CStatic class in a separate thread?

Any insight would be greatly appreciated!
Thanks,
Greg

try to use multimedia timers instead of normal timers :)

I tried that too, but it didn't work.

What I don't understand is if I am call the function that does all my drawing, from a user interface thread which is running in its own process, how can stuff that happens in my main dialog process interfere with my drawaing code for the spectrum?

Thank,
Greg

Threads, applications, and system resources all are run on the same CPU (or CPU's in a SMP system), what this means is that a appication will get a time slice to use and each of it's threads will get a portion of that slice. That means that if a process has one or more time intensive threads, they will be competing for a limited resource, time. This competition is somewhat different under SMP, but that's generally not what most folks have.

One thing that you can do is to set a higher priority to the drawing thread, which means that it will get a larger slice of time, and the for loops will get less... You may also get a noticable "return" by placing Sleep(0) -- gives up the remining time slice -- at strategic places in the for loops. The question is what's a good balance, i.e. what update delta can the user preceive (generally about 24 to 30 updates a second) vs how responsive do you want the interface to be. It may be possible for you to "look ahead" in the drawing thread, or threads, so that any computations are done before the drawing is done (like how the media player works...).

Thank you very much! I understand how everything works much better and I was able to fix my problem!

Thanks a million!!
Greg

Well a better solution might be to user the worker thread for this purpose becauze u just want to share the workload , UI thread takes more memory alongwith extra overhead due to message pumping mechanism.

Oh a worker thread does work! I didn't think it would because I am calling a function that is contained within a CStatic derived class and I read in msdn that you should not call any GUI related functions from within a worker thread..

Oh well, thanks!
Greg

Well u can do this by posting the message to cstatic derived class ,

instead of direct function call.and it will work fine.

But anyhow ure problem is solved ,
so good bye