上一个TIP里面我们用CFbsBitmap制造了一个double buffering的机制。搞游戏的都知道，画图这件事是一定要亲力亲为的。所以，我们通常想到的办法就是，自己弄一块内存，在上面想画什么就画什么，然后把画好的东西封装到CFbsBitmap里显示出来。听起来不错，可是看来看去，也找不到任何一个API允许我们从一块内存中构建一个CFbsBitmap出来！当然有一个SetScanLine()可用，这个工具允许我们一行一行地修改我们的Bitmap，但那太慢了！何况我们也不想同时保留两大块buffer啊（别忘了，用做Off-screen 的CFbsBitmap自己也占着一大块内存啊）。怎么办呢？继续看就知道喽。

CFbsBitmap的众多function中有一个叫做DataAddress()的，它就是问题的关键所在。它指向的地址其实就是CFbsBitmap封装的bitmap数据。但是不幸的是，这个地址是不能改变的，所以我们无法将它导向我们自己的buffer。所以我们必须直接利用它。简单的讲，这个流程如下：

1. 创建一个CFbsBitmap
2. 拿到他的DataAddress()
3. 直接在返回的buffer上面画图

有一些细节我们来看一看：

一、创建CFbsBitmap

代码:

iOffScrnBmp = new (ELeave) CFbsBitmap; User::LeaveIfError(iOffScrnBmp->Create(aRect.Size(), EColor16M));

这里的关键在于EColor16M。通过它，我们生成了一个24-bit的bitmap！这很重要，因为任何其他的参数生成的东西都是很难直接在内存里来玩的。因为毕竟我们的画图程序大多假设我们是在画一张24-bit的图。我们也不想花脑筋去理解那个4096色的构造是不是？

二、拿地址

代码:

struct RGB {    unsigned char b;    unsigned char g;    unsigned char r; }; ... RGB* bmp = (RGB*) iOffScrnBmp->DataAddress();

这个RGB是profx自己定义的小玩意儿。如果你不需要它，尽可以使用别的方法。比如：

代码:

unsigned char* bmp = (unsigned char*) iOffScrnBmp->DataAddress();

三、画图。

在这里我们只是简单地添一个黄色的色块（profx最爱的颜色）

代码:

int size = aRect.Size().iWidth * aRect.Size().iHeight; for (int i=0; i<size; i++) {    bmp[i].r = 255;    bmp[i].g = 255;    bmp[i].b = 0; }

搞定啦！其余的东西跟上一个TIP没大的分别了，我就不赘述了。用这个方法，我们也用不着那些个什么CFbsBitmapDevice, CFbsBitGc了。