以下部分转载于：

1 . Alpha blending

Alpha有两种模式，一种是全屏Alpha数值，另外一种是Android提供的RGBA数据进行Alpha渲染。

第一种比较简单，如果发现有全屏Alpha值，配置AMB寄存器为刷新全屏alpha，并填上alpha数据，

不过我因为三星0值为0x0，而上层为0xff，所以需要做下转换，不过全屏alpha的机会很少，看不出。

第二种就是RGBA8888数据中带有alpha值，这种情况较多，主要体现在界面上。

Android的界面基本是贴两层图，一层为背景图片（RGB565），另外一层为图标（RGBA8888）

一开始我无论如何配置，屏幕上背景都是黑色，郁闷了很长时间后才发现需要配置AMB寄存器

为alpha with bitmap模式，但是驱动里面并没有写这个寄存器。

2. Color Format Transform

颜色格式转换，因为screen是RGB565的，如果刷来RGBA8888数据，肯定要进行颜色格式转换。

这块2D引擎肯定有支持。

可是，开始配置RGBA8888转RGB565时，发现屏幕是红色的？

调试了很长时间，发现GoogleAndroid的RGBA8888竟然是大印第安序的，

手动将颜色转换配置为ARGB8888，发现白色正常，绿色和蓝色反了呵呵，

于是写了一个颜色格式软换的函数：

daddr[i]= ((saddr[i]) & 0xFF00FF00) |(((saddr[i])&0xFF)<<16)| (((saddr[i]) &0xFF0000)>>16);

也就是对应ARM的ABGR8888，这种颜色三星貌似不支持。

结果这个函数让界面的效果有所减低，为了这个转换我还用了另外一块PMEM。

昨天看三星Android1.5的内核驱动代码，竟然发现其操作了一个数据手册没有的地址（0x350）omg

在网上一搜，有的头文件将其标记位印第安序转换寄存器，顿时欣喜若狂，

这样就支持ABGR颜色格式，不用再软件转换！

试过之后，果然有用，流畅感大升，三星你果然还留了一手啊，或许我看的数据手册太老了。

3. Cache的一致性问题

因为PMEM分配的内存上层也要使用，如果不能被cache，性能会有损失。

但是6410的cache是writeback的，也就是不同步在内存中更新。

这样会导致如果图像缓存数据被cache了，屏幕上会出现一些细小的颜色错误。

目前的解决方法是启动2D引擎前flush下cache，不知道能够将cache配置为wirtethrough，

哪个性能损失小呢？

Copybit模块在android2.0以后归OpenGL管理，

在libagl中专门有一个copybit.cpp文件对其进一步封装并进行管理。

当然，也有越狱的时候，这个我们在后面讨论，首先还是看看copybit.cpp。

4. bitblit和stretch

 stretch并没有特殊去实现，因为所有的坐标数据都是Android的Surface和OpenGLES层传下来的，

主要还是实现bit blit，即块拷贝。

Android上层，主要是SurfaceFlinger，维护着几块重要的图形缓冲区。
      这些图形缓冲区是通过Gralloc模块申请到的PMEM空间，因此都可以获取物理地址，提供给2D加速引擎。

为什么只有几片缓冲区呢？我估计800x480的屏幕大约只要10MB的PMEM空间即可，这么点的数据，

如果连 续传给LCD，肯定是不够的。

因此Android采用了部分更新策略(update ondemand)，只更新屏幕是需要改变的部分，

这一点很适合2D引擎，因为引擎可以只把改变的数据刷到屏幕上。

Copybit的上层会传递两个参数，一个是当前缓冲（屏幕）的总大小，比如800x480，

另外是需要更新的窗口大小（x，y，w，h）。

最后需要注意，将数据提供给S3C6410的blit引擎前，需要区分src和dst的数据是什么（fb或者pmem），

如果是fb，传递fb基址，否则传递pmem物理地址。

5. Rotate

Rotate很简单，坐标数据上层基本做好了，刷新矩形框可以直接使用msm模块的set_rects，

配置下2D引擎的旋转模式即可。