自去年圣诞节以来，L叔和老A已经离开了小半年，毕竟热情劲过了，收入也没起色。可我独揽这个项目之后怎么觉得速度并没减慢多少？
好吧前面那句只是吐槽，其实如果没有他们的努力建立起来的基础，我也没法顺利地把这个项目继续下去。
自从上次更新了可用的motionplayer插件之后，软件渲染器的瓶颈越发明显，是时候把GPU渲染部分给完善了。
现阶段最理想的结果就是完全GPU渲染图像，但是一部分插件对GPU的支持总是落后于实际情况，还有为了兼容tjs脚本能够做像素级别的操作，与CPU交互是必须支持的。
而像素数据在GPU和CPU之间倒腾，那速度已经足够让画面变成幻灯片，还不如全程用CPU运算呢……
回头翻看一年前那试验性的opengl代码，只觉得一阵阵的蛋疼，如果要插件能干涉图像计算，势必得有一个自由灵活高效的渲染器。
于是重写渲染器的漫漫征途就这么开始了……
目前的计划是插件与内部图层对像素的计算都使用glsl脚本，这样大部分渲染都可以在GPU上进行。
软件计算则要想办法让glsl代码能在CPU上运行，直觉上应该有先人实现过了，果然一Google就有不少库声称能做到。
经过几天的查阅与试验，最后锁定在两个库上：Android 3.1起开始支持的RenderScript，和mesa3d的llvmpipe库。
前者有提供libRSSupport给低版本的android提供必要的兼容，而新版本的android直接可以将其运行在GPU上，只是现在还不知道与CPU交互像素数据会不会和opengl一样慢。
后者直接把glsl编译成本地代码运行，效率应该不错。
看RenderScript的介绍倒是挺不错的，即能在CPU上运行又能使用GPU加速，只要做一个glsl代码到rs代码的转换，就可以最大程度利用硬件资源。只是实际开码的时候发现限制太多，这个只能放到将来再引入了，到时候视开发的实际情况，要么与CPU计算互补（如果GPU与CPU之间交换数据够快的话），要么弄成软件渲染和opengl渲染之外的第三个渲染器供用户选择。
※第一次写开发日志，有挺多东西想写的，但八字还没一撇呢，那些脑洞就不写了。预计是每周更新一次日志，只是不知道能坚持多久呢？