WinCE5.0中应用程序直接写屏

      以前曾利用GAPI实现应用程序直接操作显示驱动的FrameBuffer，以提高屏幕绘图和视频播放的效率。GAPI依赖于显示驱动，必须在显示驱动中添加相应的接口才能正常使用。如果平台是我们自己定制的，在WinCE5.0中，我们也可以通过另外一种方法来操作FrameBuffer。

　　以DeviceEmulator为例，我们已经知道FrameBuffer的物理地址是0x30100000,大小为0x100000。那么在应用程序中可以通过如下代码，直接获取操作FrameBuffer的机会。

代码

1       char   * gpLCDBuf;
2      gpLCDBuf  =  ( char * )VirtualAlloc(NULL, 0x100000 ,MEM_RESERVE,PAGE_NOACCESS);
3      VirtualCopy(gpLCDBuf, ( void   * )( 0x30100000 / 256 ),  0x100000 , PAGE_READWRITE  |  PAGE_PHYSICAL  |  PAGE_NOCACHE);
4      memset(gpLCDBuf, 0xFF , 0x100000 );    
5      VirtualFree(gpLCDBuf, 0 ,MEM_RELEASE);

  　 以上示例代码是将屏幕刷白，当然也可以将它刷黑，或者其他纯色，这样便可以做一个WinCE5.0下测试LCD的小工具了。

　　在编译以上代码时，需要包括头文件pkfuncs.h。编译时还可能会出现如下错误,

　　C:/WINCE600/PUBLIC/COMMON/OAK/INC/pkfuncs.h(1042) : error C2065: 'REG_TYPE' : undeclared identifier

　　简单的处理方法就是在代码中添加一个宏定义，如下,

　　#define REG_TYPE DWORD

　　对话框的全屏显示，可以通过如下代码实现,　　

1      DWORD dwWidth  =  GetSystemMetrics(SM_CXSCREEN);
2      DWORD dwHeight  =  GetSystemMetrics(SM_CYSCREEN);
3 
4      ::SetWindowPos( this -> m_hWnd,HWND_TOPMOST, 0 , 0 ,dwWidth,dwHeight,WS_EX_TOPMOST);

 

 

 

原文：http://www.cnblogs.com/we-hjb/archive/2010/02/06/1664754.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的显存中直接保存下来的，如下图所示。

             

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

            

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

             

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

             

      很明显，直接写显存比使用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