顶多编辑器里面设置的好直接走配置，别实时计算了，动态赋值这好像也没啥好的处理方案吧
发现一个小Bug 在编辑器内新建一个场景，不执行保存场景的操作下，这个场景的 json里的uuid是一个默认的 uuid 但是右键显示这个场景的uuid是正确的，执行保存场景操作后场景 json内的uuid才被刷新成正确的uuid
这会有什么问题么
RichText的measureText消耗是必定的，
不算又怎么能实时调整内容呢。。。。
我们聊天栏的优化也就是分帧计算出每行的meta（记录行高、行宽、可直接用于创建Label或Image的文本fragment列表），
结合视图裁剪及Label复用，
才将性能消耗降低到可接受的程度。
这问题会导致构建后的 场景json 内的场景id好像是一个随机值。就我测试发现引发的问题是 导致热更的 场景json文件md5值每次都是变化的，是否有其他并发问题暂时没有发现
能不能帮忙解决下这个问题
文本再如何动态变化也不太可能每帧都发生变化.计算最大占用宽度是个耗费时间的过程.应该缓存下来.侦测改动文本的api,发出文本改变事件,发生改变才重新计算.否则就一直使用缓存的计算结果.虽然我没有看引擎源码是否是这样实现.但理论上这是比较高效的计算动态文本的宽高度实时数据了.
2.3是你说的这样
我看了下源码 竟然传的是0.25。。。是不是自动合图导致的。。。
2.3正式版什么时候发呀，等着发ios版本呢啦
这两天有个测试版还是很香得
感谢各位大佬，快过年了还这么积极地使用 Creator
你们哪里已经开始过年了？
你们已经放假了？我们还有新需求还没做呢
没放呢，战斗到最后
关于骨骼动画挂载点，有个疑问想请教下。
是否至少一定要将整个挂载点的层级节点保留？
比如New Sprite是要挂到某个bone上的一个节点，
那么这个bone及它的父节点是不能删除的吧？
对的，父节点不能删
所以最少保留节点是直系父节点了。。。
其实这个信息可以通过一个树状结构存储的吧？
不用依赖节点来存储吧？
用节点存储感觉有点浪费。
空节点还好，主要是不保持节点的树状结构，原本节点树的一些功能就得单独写一套，比如opacity级联，这种，又得单独撸一套节点的数据结构，也不见得就会少多少内存，代码还会冗余不少。
动画编辑器感觉还是很不爽····不能快速定位关键帧的时间轴 添加关键帧也比之前要多选一步不能直接添加····有计划优化这方面么?以及目前这个版本没法添加rotation和opacity属性····