WinCE显示资源中BMP图片的几种方法对比

本文是转帖,原帖地址

http://www.cnblogs.com/we-hjb/archive/2010/02/09/1666778.html

 

 

前面介绍了如何直接操作WinCE的FrameBuffer,这里将介绍一种通过写FrameBuffer显示资源中BMP图片的方法。并与使用GDI做一个比较,看看直接读写FrameBuffer是否能提高效率?

      采用GDI的方法,关键代码如下:

    hScrDC  =  CreateDC(TEXT( " DISPLAY " ),NULL,NULL,NULL);
    hMemDC 
=  CreateCompatibleDC (hScrDC);
    bmp.LoadBitmap(MAKEINTRESOURCE(IDB_BITMAP1));
    bmp.GetBitmap(
& bmpInfo); 
    SelectObject(hMemDC,bmp);

    BitBlt(hScrDC,
0 , 0 ,dwWidth,dwHeight,hMemDC, 0 , 0 ,SRCCOPY);

       采用直接写FrameBuffer的方法,关键代码如下:

    HINSTANCE hInst  =  (HINSTANCE)::GetModuleHandle(NULL);
    HRSRC hrc 
=  FindResource((HMODULE)hInst,MAKEINTRESOURCE(IDB_BITMAP1),RT_BITMAP);
    HGLOBAL hGlobal 
=  LoadResource(NULL,hrc);
    dwBufSize 
=  ::SizeofResource(NULL,hrc);
    gbmpBuf 
=  (PBYTE)::LockResource(hGlobal);

    memcpy(gpLCDBuf,gbmpBuf,dwBufSize);

       资源中加载的BMP图片是从WinCE的显存中直接保存下来的,如下图所示。

              image

      使用BitBlt显示的效果如下图所示。

             image

      直接写显存的效果如下图所示。

            image 

      可以看到采用BitBlt,资源中的BMP似乎被真实显示。采用直接写屏的方法颜色被还原了,但往右偏了一些。他们分别使用的时间如下图所示,GDI使用了145ms,直接写显存大概1ms。

            image 

      很明显,直接写显存比使用BitBlt快很多,但位置有偏差。那么用GDI能否有更快的方法?它为什么这么慢。又尝试着用了GDI的另外一种方法显示。代码如下:

    bmi.bmih.biSize  =   sizeof (bmi.bmih);
    bmi.bmih.biWidth 
=  dwWidth;
    bmi.bmih.biHeight 
=   - dwHeight;
    bmi.bmih.biPlanes 
=   1 ;
    bmi.bmih.biBitCount 
=  (BYTE)bmpInfo.bmBitsPixel;
    bmi.bmih.biSizeImage 
=   0 ;
    bmi.bmih.biXPelsPerMeter 
=   0 ;
    bmi.bmih.biYPelsPerMeter 
=   0 ;
    bmi.bmih.biClrUsed 
=   0 ;
    bmi.bmih.biClrImportant 
=   0 ;
    bmi.bmih.biCompression 
=  BI_BITFIELDS;
    
* (DWORD  * )( & bmi.rgq[ 0 ])  =   0xF800 ;
    
* (DWORD  * )( & bmi.rgq[ 1 ])  =   0x07E0 ;
    
* (DWORD  * )( & bmi.rgq[ 2 ])  =   0x001F ;

    StretchDIBits (hScrDC, 
0 0 , dwWidth, dwHeight,  0 0 , dwWidth, dwHeight,
        gbmpBuf, (PBITMAPINFO)
& bmi, DIB_RGB_COLORS, SRCCOPY);

   采用这种方法,显示效果和DDraw完全一样,速度也不相上下,同样比BitBlt快很多。这是为什么呢?玄妙就在bmi.rgq,这里设置的BIT MASK与显示驱动中一致,所以,效果相当于直接写屏,颜色也对了,效率也高了。而BitBlt默认的BIT MASK估计与驱动中的不一致,从而导致多做一些内存运算,花费了一些时间。为了验证这个想法,修改bmi.rgq的设置如下:  

   在实际开发过程中,这个小细节可以注意一下,也许可以提高一些效率。

     * (DWORD  * )( & bmi.rgq[ 0 ])  =   0xF800 ;
    
* (DWORD  * )( & bmi.rgq[ 1 ])  =   0x03E0 ;
    
* (DWORD  * )( & bmi.rgq[ 2 ])  =   0x001F ;

   这种情况下,颜色显示与BitBlt一样,使用的时间也差不多。看来并不是使用GDI就一定会慢,BIT MASK才是关键。16位色的BIT MASK主要有以下几种。

     //  XRRRRRGG.GGGBBBBB 0x7C00 0x03E0 0x1F
    
//  RRRRRXGG.GGGBBBBB 0xF800 0x03E0 0x1F
    
//  RRRRRGGG.GGXBBBBB 0xF800 0x07C0 0x1F
    // RRRRRGGG.GGGBBBBB 0xF800 0x07E0 0x1F

 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值