creator渲染命令的提交顺序依然取决于 场景树的布置，并没有解耦，对于纹理不同(比如图集不同)，shaderProgram的不同，blender模式的不同，都会打断合批。
对于creator的渲染，我有个不成熟的猜想。收集渲染命令后，在渲染之前，排一下序，对于UI的深度排序，比如 用一个 0.1-0.2之前一个float值去赋予场景树中的每个渲染节点。渲染的上下的层级完全交给GPU去掌控。这样可以最大程度合并vertexbuffer。
好吧，这只是我根据目前对OpenGL的了解和见闻，自己的一个观点。
那层级不就错乱了？
我表述不太清晰：
“收集渲染命令后，在渲染之前，排一下序，对于UI的深度排序，比如 用一个 0.1-0.2之前一个float值去赋予场景树中的每个渲染节点。渲染的上下的层级完全交给GPU去掌控。”
并不是打乱节点的场景树层级，而是把收集到的命令对象按照某种方式排序，根据场景树层级给渲染命令对象去设置一个float z值，作为GPU的深度测试依据。
比如这个图。按照依赖场景树的渲染模式，绘制顺序是不是 a,b,c,d,e,f,g，对不对。然而这个是非常容易打断合批的，绘制顺序完全不需要依赖这个“场景树层级”（场景树层级用来做 事件分发还是很完美的，但是用于做渲染顺序确实不好）。
假设 a,e,f是同一个图集，我可以先绘制a,e,f嘛，然后再绘制别的， 层级顺序根据一个z交给GPU深度测试不就OK啦。
举个最简单的例子，我用OpenGL自己写demo的时候，比如上图的层级， a,e,f是球，b,c,d,g是立方体。如果，按照场景树的层级提交绘制，岂不就打断了合批。
那这个排序开销呢？
所以问题在于，排序开销大，还是打断合批的代价大。。。
zIndex不就是干这个事的吗？
不是。zindex只是改变了父节点对于子节点们层级排序的依据，原理还是一样的。
问题在于·····
你可以自己去手动用图集，
这样，又能合批，又能省下排序~
你觉得怎么样？
无法实现的, 这样做之后, program无法灵活定制.
只希望官方能降低耦合度.
比如自己写一个programA， 比如自己100个物体用programA，渲染对象提交顺序恰当的话，还是可以合批的。
问题是2d引擎只有xy,没有z，层级关系都是靠渲染顺序决定了，如果你改了渲染顺序是可以达到完美的和批渲染效果，但是最后可能和预计的表现出入很大，节点与节点之间的层级就乱了。
其实排序的开销并不大，你可以自己维护一个渲染队列。
节点层级不会乱呀。
你看完这个帖子自然就会懂了
1赞
看了一下大神的帖子。不过我还是没有找到想要的答案。我再自己琢磨琢磨，然后再组织一下语言
感觉你描述的不是很清晰。
你描述的东东似乎不能解决透明混合的情况吧
被你们说的我都不敢随意定制shader了. 我很多情况下, 能用sprite解决的问题, 往往刻意用shader…
开启深度检测来让 GPU 帮助我们剔除不需要的面片确实是一个很好的思路，然而它的限制就像上面的回复说的，无法解决半透明混合问题。深度检测是面片级的，GPU 的深度检测只能决定在渲染的时候剔除被前景遮住的像素，它并不能告诉你前景像素是透明的、半透明的还是不透明的，只会简单粗暴得剔除像素，让其不进入后续的 fragment shader 着色。所以在常规的 2D UI 渲染过程中或者在 3D 半透明渲染流程中，都需要将被渲染物体按照从后向前的顺序排序后逐个渲染，这样前后物体之间的半透明混合才是正常的