后续会考虑支持吗？可以添加宏支持判断，不支持走另一套逻辑
有没有优化shader graph的打算？比如优化界面，增加些节点之类的，或者内置到版本模块里
抱歉，目前没有
WebGL、GLES2本身不支持sampler2DArray，可以通过sampler2D[]模拟。
但这对整个资源存储、排版、shader生成有影响，而且sampler2D[]只支持小数组。
用宏判断的话，需要写两份shader、两套管线逻辑。这可以通过自定义管线可以做到，但比较复杂。
引擎内部目前没这样的抹平需求，估计不会支持。
- 如果要求
sampler2DArray，那么就不会支持WebGL、GLES2这两个平台。 - 如果要求
sampler2D[]大数组，会要求硬件支持bindless，也不支持WebGL、GLES2这两个平台。
昨天有其它任务，今天看下
兄弟，你应该跟这两条是同一个问题吧。
这个问题是此版本引入的，还是历史版本都有的问题？
项目是从2.4.x升上来的，在2.4.x的时候深度测试都是正常的，升到3.8.6之后加入了RenderRoot2d就不正常了，目前只能通过手动排序解决吗？spine多的时候手动排序会有性能问题吧。另外粒子特效总是在2d对象的底层问题怎么解决？排序无法解决该问题。
另外我尝试将所有2d对象的材质开启深度测试和深度写入，层级正常了，但是有个问题就是spine会有zfighting问题。
这表示3.8对此问题无解吗
好的，了解了 
嗯，发送 Pull Request 到官方仓库即可。
目前在 android 6.x 上的什么浏览器（系统浏览器 or Chromium 系列的浏览器）上运行会出现问题？浏览器版本是？不能运行是有脚本异常吗？
粒子特效只开启了depthtest，没有开启depth write，肯定还是使用的画家算法，spine走的渲染流程是ui的流程，ui在管线中默认是最后渲染的，所以按照先提交先绘制的原则，粒子必然在spine的下面。手动排序为什么会有性能问题？节点多，懒得拖的话确实会有开发效率的问题。你如果有很多spine，又开启了深度写入，反而会引起性能问题吧？因为你的spine在ui流程是不会经过提交之前的深度排序的，导致gpu early z不会发生，深度对比又会更加频繁
是createbitMap第二个参数传入{}对象导致崩溃，然后在promise完成后可能imageBitmap.close函数不存在，测试设备为Vivo y66,系统版本6.0.1(funtouch_os 3.0),处理器是MSM8937.我们是应用内webView运行游戏，所以卡在那了
附带的报错信息：
对了，还有就是引擎内使用了Object.entries()函数，在老一点的浏览器里也没有这个接口，所以如果要兼容6.x,需要预处理一下。我是重新实现了这个接口
if (!Object.entries) {
Object.entries = function (obj) {
const ownProps = Object.keys(obj);
let result = [];
for (let i = 0; i < ownProps.length; i++) {
result.push([ownProps[i], obj[ownProps[i]]]);
}
return result;
};
}
spine还有新问题，demo已发私信，麻烦关注下，谢谢！
3.8.6正式版多久出呢