为什么不在后台线程上编译着色器？

Question

我一直在通过查看代码和开发人员视频来学习OpenGL ES 2.0 / GLSL和相关的iOS怪癖，我注意到从未提及异步着色器编译。除了担心增加示例复杂性的教师，作家或推销员（呃，工程师）之外，有没有理由呢？

例如，大多数网络数据检索教程都需要做一些体操（pthreads，NSOperation，GCD，在异步实例方法中烘焙等）以防止阻塞主线程 - 为什么阻止应用程序启动被认为是可以接受的吗？

Answer 1

同步两个EAGLContext可能有点棘手，除此之外，没有什么可以反对在后台加载这种东西（通常，加载各种资产，纹理，着色器等） 。

可能真正的原因可能是大多数人认为OpenGL（ES）是单一的，只能在一个单独的线程上工作，或者他们从来没有加载时间的问题，这使得在后台线程中加载东西是值得的，或者他们只是不关心（对某些人而言，它可能是一切）。

对于你的上一个问题：网络可以增加一个巨大的潜力，而“可以”我的意思是“将”。与网络访问相比，资源加载不是那么有问题，加载着色器或纹理会占用更少的时间，并且已经知道在正常情况下需要花费多少时间。此外，人们习惯于在游戏中加载屏幕，而他们不希望在滚动表格视图时看到加载屏幕，以便您的应用程序可以从无响应的服务器获取图片。