Improve item icon export: unified sizes, 3D block dynamic icons, and lossless PNG compression

[XSana]

Summary

• 单帧图标统一导出为 256px；动图按实际分辨率导出，size / frameCount 字段只记录动图。
• 3D 方块动图改用 256px 渲染，避免低分辨率 FBO 把模型压小、产生异常留白。
• 所有导出的 PNG 启用最高压缩等级（无损），大幅减小文件体积。

Details

图标尺寸

• 新增 SINGLE_FRAME_SIZE = 256，普通单帧固定 256px 渲染。
• 动图长图 icon_*_dynamic.png 按动态纹理实际尺寸；3D 方块动图用 256px。
• size（动图单帧高度）和 frameCount 仅对动图记录，静态图为 null。

无损压缩

• FBOHelper.saveToFile 从默认 ImageIO.write（零压缩）改为 ImageWriteParam 最高压缩等级写 PNG。
• 对所有图标生效（静态图、动图首帧、动图长图），分辨率/帧数/像素均不变。
• 实测大文件降幅 8%~55%，例如 icon_Avaritia_Dire_Crafting_dynamic.png 从 4.9MB 降到 2.2MB。

[iouter]

1.物品按实际大小导出就是单纯的为了减少体积，导出更大的没意义，我认为通过css设置为邻近放大就行了
2.3D方块本来就是256导出的
3.不要改文件名，要稳定

[XSana]

1.物品按实际大小导出就是单纯的为了减少体积，导出更大的没意义，我认为通过css设置为邻近放大就行了 2.3D方块本来就是256导出的 3.不要改文件名，要稳定

文件大小可以通过无损压缩进一步压缩大小，是否保留256都行，我按照前面的要求做到调整，如果不需要可以回滚掉，不过这会连带出另一个问题，如AE线缆等物品他不是itemblock，现有3D物品检测判断不到这个，会导致降级成16px然后图标会糊掉，包括不限于AE物品 GC火箭等，文件名字没动，我只加的PNG无损压缩。目前对于动态物品按照实际大小导序列，block保持256

[iouter]

1.物品按实际大小导出就是单纯的为了减少体积，导出更大的没意义，我认为通过css设置为邻近放大就行了 2.3D方块本来就是256导出的 3.不要改文件名，要稳定

文件大小可以通过无损压缩进一步压缩大小，是否保留256都行，我按照前面的要求做到调整，如果不需要可以回滚掉，不过这会连带出另一个问题，如AE线缆等物品他不是itemblock，现有3D物品检测判断不到这个，会导致降级成16px然后图标会糊掉，包括不限于AE物品 GC火箭等，文件名字没动，我只加的PNG无损压缩。目前对于动态物品按照实际大小导序列，block保持256

AE线缆。。头晕啊，如果没有别的办法，要么特判，要么统一256了

（你说，导出成矢量图有没有搞头（））

[XSana]

1.物品按实际大小导出就是单纯的为了减少体积，导出更大的没意义，我认为通过css设置为邻近放大就行了 2.3D方块本来就是256导出的 3.不要改文件名，要稳定

文件大小可以通过无损压缩进一步压缩大小，是否保留256都行，我按照前面的要求做到调整，如果不需要可以回滚掉，不过这会连带出另一个问题，如AE线缆等物品他不是itemblock，现有3D物品检测判断不到这个，会导致降级成16px然后图标会糊掉，包括不限于AE物品 GC火箭等，文件名字没动，我只加的PNG无损压缩。目前对于动态物品按照实际大小导序列，block保持256

AE线缆。。头晕啊，如果没有别的办法，要么特判，要么统一256了

（你说，导出成矢量图有没有搞头（））

对，AE线缆哪些基类是Item不是ItemBlock，但是只特判他不够，GC火箭也是，具体有多少不太清楚除非拉表。

矢量图理论上能做，但是具体情况具体看，比如16px的svg表示同样像素图的png体积可能更大或更小（通常更大），具体取决于图片复杂度。只能限16px更大的大概率svg不如png。即不同像素越不连续png越省，反之svg更省因为连续色块可以用一个rect表示。对于MC图标 90%我觉得png在开最高级无损压缩的情况下会比svg更小。

以这个图标为例，显然svg更大，不过肯定比256的png小，svg放大天然优势。