下面两个代码段实现的是同样的功能,将一幅图缩放2倍后输出到窗口,第一段是用Sleep函数来等待一段时间,第二段是用WaitForSingleObject函数来等待一段时间,但是实际运行时第一段代码基本上不占用CPU,第二段代码却占用了20~30%左右的CPU。
占用这么高CPU的原因我知道,是因为调用了图像拉伸的API函数StretchDIBits,去掉这个函数调用后两个代码段基本上都不占用CPU,但是两段代码同样都调用这个函数,为什么第一段代码基本不占用CPU呢?//segment 1
void ThreadProc(LPVOID lpParam)
{
clock_t lPreClock, lCurClock;
double duration;
double interval; lPreClock = lCurClock = clock(); while(TRUE)
{
if(bExit)
{
printf("Thread exited!");
return;
}
lCurClock = clock();
duration = lCurClock - lPreClock; if(duration < 40) //间隔小于40毫秒,不绘制
{
Sleep(1);
continue;
} lPreClock = lCurClock; DrawPicture();
}}//segment 2
void ThreadProc(LPVOID lpParam)
{
DWORD dwRet;
while(TRUE)
{ dwRet = WaitForSingleObject(hExitEvent, 5); //hExitEvent:退出事件对象
switch(dwRet)
{
case WAIT_OBJECT_0:
printf("Thread exited!");
return;
case WAIT_TIMEOUT:
{
DrawPictrue();
}
break;
}
}
}
占用这么高CPU的原因我知道,是因为调用了图像拉伸的API函数StretchDIBits,去掉这个函数调用后两个代码段基本上都不占用CPU,但是两段代码同样都调用这个函数,为什么第一段代码基本不占用CPU呢?//segment 1
void ThreadProc(LPVOID lpParam)
{
clock_t lPreClock, lCurClock;
double duration;
double interval; lPreClock = lCurClock = clock(); while(TRUE)
{
if(bExit)
{
printf("Thread exited!");
return;
}
lCurClock = clock();
duration = lCurClock - lPreClock; if(duration < 40) //间隔小于40毫秒,不绘制
{
Sleep(1);
continue;
} lPreClock = lCurClock; DrawPicture();
}}//segment 2
void ThreadProc(LPVOID lpParam)
{
DWORD dwRet;
while(TRUE)
{ dwRet = WaitForSingleObject(hExitEvent, 5); //hExitEvent:退出事件对象
switch(dwRet)
{
case WAIT_OBJECT_0:
printf("Thread exited!");
return;
case WAIT_TIMEOUT:
{
DrawPictrue();
}
break;
}
}
}
{
Sleep(1);
continue;//把这行去掉,CPU应该上去,这不叫漏帧?
}
切换了cpu的控制权
2里面有可能会空循环,占cpu就多
StretchDIBits是相当费时间的,
GDI+缩放的效率要好很多,推荐用
如果自己写缩放函数,或用第三方库现成的,把中间BUF提出来,还会比GDI+好一点点GDI+的缩放函数写的很效率,不过它内部每次都要新建和释放那个中间Buf,图片越大那个Buf也越大
谢谢 大家共同学习 前段时间我做监控程序客户端也遇到这个问题,16个窗口软解码、显示确实太占CPU,刚开始9个窗口就用了60%的CPU,优化了好长时间才降下来。现在用第二段程序wait时间设置为40毫秒还是占用10%左右的CPU,但是第一段程序每次Sleep(1)就基本上不占用CPU了,看来还有这个continue的功效。这个版本就先用Sleep+continue了,有时间再优化吧
这个当然是不一样的,刷的快占cpu就大了,因为相同时间内执行的东西多
http://www.cnblogs.com/shootingstars/articles/24602.html。