如何在Android上加速着色器加载编译

概述我为 Android编写了一个OpenGL动态壁纸,它使用了17个像素和17个顶点着色器.在我的HTC Legend上,加载和编译大约需要3秒钟.加载时间约为20％,剩下的就是编译. 每次运行全屏应用时,动态壁纸都会破坏其OpenGL上下文,当壁纸再次可见时,需要重新加载所有着色器,纹理等,导致屏幕每次冻结约3秒,这对我来说是不可接受的:( 我做了一些阅读,显然,不可能预编译着色器.我还能做些什么 我为 Android编写了一个OpenGL动态壁纸,它使用了17个像素和17个顶点着色器.在我的HTC Legend上,加载和编译大约需要3秒钟.加载时间约为20％,剩下的就是编译.

每次运行全屏应用时,动态壁纸都会破坏其OpenGL上下文,当壁纸再次可见时,需要重新加载所有着色器,纹理等,导致屏幕每次冻结约3秒,这对我来说是不可接受的:(

我做了一些阅读,显然,不可能预编译着色器.我还能做些什么来解决这个问题？是否可以在后台线程中加载和编译着色器？在这种情况下,我可以展示某种进展动画.不会很好,但总比没有好……

[EDIT1]
加快这一速度的另一个重要原因是整个基于OpenGL的动态壁纸生命周期很难在所有设备上正常工作(这是轻描淡写).每当上下文丢失/重新创建时引入长加载时间会增加比我想要的更多麻烦.无论如何：

正如答案1所示,我尝试查看GL_OES_get_program_binary扩展,以制作某种编译一次存储编译版本的安装应用程序,但我担心这个扩展的实现范围有多广.例如,我的Tegra2平板电脑似乎不支持它.

我正在考虑的其他方法：

1)Ubershader：将所有像素着色器放入一个大的着色器中,使用switch或if语句.这会大大减慢像素着色器的速度吗？它会使着色器太大并让我超过所有那些讨厌的寄存器/指令计数/纹理查找限制吗？顶点着色器的想法相同.这会将我的整个shadercount减少到1个像素和1个顶点着色器,并希望能够更快地编译/链接批次.有没人试过这个？
[EDIT2]我刚试过这个.别.编译/链接现在需要8秒才能放弃模糊的“链接失败”错误:(

2)穷人的后台加载：不要在开始时加载/编译着色器,而是为前17帧加载/编译每帧更新一个着色器.至少我会刷新显示,我可以显示一个进度条,让用户看到正在发生的事情.这可以在慢速设备上正常工作,但在快速设备上,这可能会使整个着色器加载/编译阶段比它需要的慢…

解决方法 检查您的实现是否支持 OES_get_program_binary. 总结

以上是内存溢出为你收集整理的如何在Android上加速着色器加载/编译全部内容，希望文章能够帮你解决如何在Android上加速着色器加载/编译所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。