Creator编辑器槽点和改进建议（追加纹理压缩缓存）

Creator 2.x
#29

什么版本会有，加上纹理压缩之后，构建时间一个多小时，急需这个功能

#30

我最近也在研究这个问题，目前的方案是构建的时候把pac都删掉，正式出包的时候才真正合并图集

#31

我这里有个改进思路，要引擎组实现：
1 第一次纹理压缩时，记录每个图片的md5，缓存在一个文件里面
2 后面每次压缩，对比md5是否发生变化，如果新增或者是改变之后才重新压缩

之前creator不带纹理压缩功能时，我们自己实现时，也是这么做的，希望引擎大佬改进下

@jare

1赞
#32

更新：
追加：纹理压缩缓存

#33

就像unity的这个复制组件功能，怎么实现

#34

我们也有这个需求， 同求

#35

已实现，将在 2.2.2 落地

1赞
#36

求跳过 2.2.1 直接发 2.2.2

#37

这个在打包时候尤其明显，那时间直接延长了两倍啊。无法忍受呀，尤其是在调试 jscallJava / javacallJs,
头都能大一圈。不得不删掉之前压缩文理的部分。

#38

自从发现每次构建都是重新计算一遍图集我就放弃用自动图集了，改为TP打好再压缩下丢工程里用了，这样反而包体还小了。
事实上它构建时打出的图集和预览时产生的图集是一样的。
毕竟图集产生时用的算法及设置参数相同的情况下是不会变的，对比下预览缓存目录的图集算法及参数，构建时参数相同则直接复制过来就可以了啊。没有的情况下才再去生成一个多好。。。。

#39

@EndEvil

#40

2.1.2 就没有重新构建图集了

#41

纹理压缩缓存挺重要的，每次构建都要重新压缩耗时太长。
本来想用gulp转etc1，用上gulp-cache，结果转完了读的还是png原图，没搞清楚引擎是怎么确定应该读pkm还是png

#42

2.2.1没跳过，2.2.2倒是跳过了，直接2.3了:smiley:

#43

泪崩:joy:

#44

迫切需要：
纹理压缩缓存
资源和脚本分开导出

项目大了，到后期接sdk，改动一点点脚本，全部资源+脚本都要重新导出纹理压缩，没几个小时下不来

#45

这个确实，一眼觉得这个不优化也没啥，但是一碰到父节点适配选四个位置就会在内心吐槽一遍

#46

toggle组件 加个隐藏背景的选项， 不是每个开关都只需要把checkmark叠加显示在上面:weary:
很简单的功能 但是每次自己写很烦

#47

问题：构建时，纹理压缩过程是单任务，即每次只会压缩一个图片，不能发挥CPU的多核性能，图片较多时，压缩过程极为漫长。
建议:增加根据CPU规格情况开启多任务分批处理资源的功能，尽可能发挥CPU的多核性能，节省构建时间

#48

可能是因为这个原因，改成了单任务