最近自己在写一个绘图软体 被一些问题卡住了 想跟大家讨论看看 我想要写一个类似 Photoshop 的图层系统 这个系统要可以同时容纳 1. 可切换各种混色模式的绘图图层 以及 2. 其他一些具有调整效果的参数图层 我以 C++ 将它实做为类似 Link List 的资料结构 也就是将每个图层设计为一个物件 此物件含有图层本身的资讯（图像或调整参数）以及一个指向下一图层的指标 实际混色时是使用递回方式 也就是每个图层都先呼叫下一图层的混色函数 然後再将自己这一层的资讯叠加到 Buffer 上去 递回到碰到最底层为止 从行为上来说这个设计是没有问题的 但是我发现当图层增多到一个程度之後 时间和空间上的开销都会有点不合理 以空间而言 假设一张图是 3000*2000px 的 RGBA 格式 那麽不压缩的大小就是 24M bytes 由於任何一个图层有改变时 都必须将混色结果即时显示到萤幕上 因此所有图层资讯都要同时载入记忆体 这种情况下 只要开20 个绘图图层 就已经用掉 480M 的记忆体了 但我用 Photoshop 作实测 它用的记忆体连我所预估的一半都远远不到 如何做到这点让我颇为好奇...... 我想过几种改善的可能 例如将「目前工作图层」以下的所有图层都存进硬碟 只将这些「以下图层」混色过後的结果载入记忆体 但这方法得要烧香拜佛 祈祷使用者多编辑上方图层 少编辑下方图层..... 我还想过是否可以用这种预计算的方法对付「所有以上图层的结合」 但由於图层的某些混色模式和某些调整颜色的演算法 都必须先决定下层图层的颜色才能计算 所以这想法似乎也行不太通 不晓得在这方面各位有没有什麽高见？ 另外一个问题则是时间上的： 假设使用者开了100个图层而且都没关掉 （一般修图情况下调整图层比绘图图层多出数倍是正常的） 又将视窗画面缩放到可以看到全图的话 那麽必须做的即时运算 竟然有 3000*2000*100 = 100M 次混色之多！！ 即使我已经对混色演算法做了 bitwise 的优化 但每次混色毕竟还是包含多次的是否判断式、加法、乘法、位移......等等 从现实情况上来说跟本不可能来得及 （流畅动画的最低标准是 24fps，也就是最慢0.04秒内要完成全部混色动作） 我想过一个改善方式 就是对每个像素侦测「是否已经掩盖下层图层」 换句话说 如果有某个像素在某一层的 Alpha 值已经是 FF 那就可以不用管他下面是三小了 但後来发现这方法会快速地在不同图层间切换 造成 Cache 效率极差 反而不如整张一起算 老老实实的算到底XD 总之 我实在是想破头也想不出好方法 关於这两个问题 如果有人能给我一点方向 我会非常感激 ^^” -- 直接阅读《琴剑六记》 http://gs.cathargraph.com/p/list.html 　　《琴剑六记》Facebook专页 https://www.facebook.com/GSannals --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 61.62.253.66