CPU使用过高的时候会不会出现Timer和实际时间不一样的情况？
我的WM程序需要进行mp3编码,在编码过程中CPU使用率比较高,大概在60~80%的样子
这个时候我显示时间的Timer和实际的时间相差比较大诶,大概一分钟就相差3~5秒的样子
这个会不会是因为CPU使用太高的缘故? 毕竟Timer很低优先级...
如果是的话有没有什么东西可以代替Timer的,比较实时的那种
[解决办法]
会呀，timer是event base，你的UI线程挂起就处理不了了。
[解决办法]
楼主用的是什么语言？
C#下就有两个Timer
一个是System.Threading 命名空间下的。
一个是System.Windows.Forms 命名空间下的。
[解决办法]
自己开一个线程，然后在线程里面用一个死循环（或者事件触发）做一个定时器
好像这样：
DWORD WINAPI ThreadFunc(LPVOID lparam){ for(;;) { if(GetTickCount()-oldtime>1000) //1秒钟到了 { oldtime=GetTickCount(); PostMessage(.....); //发送消息去你想要的窗口，让那个窗口去处理事物 } }}
[解决办法]
9楼的ThreadFunc函数的进入不会晚，但是POSTMESAGE的响应是没有保证的。
[解决办法]
首先，PostMessage之类的东西肯定是不准的。其次UITimer也是不准的。再次不知道我理解的对不对，你的要求似乎很简单。只是希望显示的时间和实际使用的时间一致。如此，只要使用当前时间减去开始时间即可。如果说你需要你媒体解码的步调和实际的播放时间一致。这个没做过，不过办法很多。不知道什么办法更更好。1）找一个精度更高的时钟(MMITimer还有一个什么Performance的)。保证你的解码速度。
2)自己通过取得当前时钟计算时差。前提也是保证解码速度。
[解决办法]
http://blog.csdn.net/BEYONDMA/archive/2010/01/08/5156652.aspx建议楼主可以看一下我的博客！
[解决办法]
不应该使用定时器计时，应该每次获取系统时间，系统时间总是准的，
获取系统时间的间隔可以短一些，但是如果系统太忙的话顾不过来也没办法，那是计算机的问题，跟你没关系。
[解决办法]