╰☆╮EvilCode的专栏╭☆╯

转自：http://mobile.51cto.com/amedia-376055.htm图形操作可以有两种方式实现：一是利用通用CPU模拟图形操作；二是利用GPU专门做图形操作。前者会增加CPU的负担，在现在高分辨率已经是普遍现象的时候，让通用处理器来完成大量的图形计算已经不现实。Android图形系统的发展过程也验证了这一观点。为了达到高效的图形处理效果，是必须紧密结合软件和硬件

转自：http://blog.csdn.net/tung214/article/details/36628897以下在Android 4.4平台开发测试，用于在屏幕直接显示RGB数据，当然，如果要直接显示YUV，写个函数转换一下也能直接显示。其中从文件中获取RGB的RGB数据可以从这里下载 http://kc.cc/WeVp[cpp] view plai

上一篇文章主要是参照AwesomePlayer直接用SoftwareRenderer类来显示yuv，为了能用到这个类，不惜依赖了libstagefright、libstagefright_color_conversion等动态静态库，从而造成程序具有很高的耦合度，也不便于我们理解yuv数据直接显示的深层次原因。    于是我开始研究SoftwareRenderer的具体实现，我们来提取So

转自：http://blog.csdn.net/tung214/article/details/36887041研究了一段时间Android的surface系统，一直执着地认为所有在surface或者屏幕上显示的画面，必须要转换成RGB才能显示，yuv数据也要通过颜色空间转换成RGB才能显示。可最近在研究stagefright视频显示时发现，根本找不到omx解码后的yuv是怎么转换成RGB