MS RFC 99:删除对gd渲染器的支持¶
- 日期
2013／06
- 作者
托马斯堡
- 联系
- 状态
采用
- 版本
MAPServer 7
1。总结¶
保持对gd呈现库的支持将阻止MapServer转向功能更完整和可维护的文本/标签管道。这个RFC建议我们在即将发布的7.0版本中取消对gd渲染器的支持，除非gd中只包含一些被忽略的用例，和/或有人有足够的兴趣为高维护开销提供资金。
1.1史¶
最初，gd库是MapServer支持的唯一一个生成位图图像的渲染器（例如，对于png、jpeg和gif输出格式）。
以大量代码复制为代价，后来又增加了对SVG、PDF和SWF的支持。
2007年，又以另一个主要代码重复为代价，增加了agg支持，在尝试与gd专有的内部像素表示一起工作时，还存在一些不寻常的问题。
2011年，对于6.0版本，渲染引擎发生了一次重大的重写，以减少先前代码重复导致的维护问题。当时已经讨论了放弃对gd的支持，但最终只保留了8bit模式，代价是维护人员的世界负载更高。与此同时，agg成为了mapserver库中的一个中心组件，并用于其他渲染器不支持的某些渲染任务。
2012年，对于6.2版本，对gd的支持成为可选的，可以在编译时禁用。
1.2当前GD限制¶
在支持高级文本/标签呈现的过程中， MS RFC 98:标签/文本呈现大修 ，gd api的局限性已经显示为向前移动的一个showstopper。保持对gd的支持将需要在新管道旁边维护当前的文本呈现管道（以维护噩梦为代价），或者需要一个非常重要的开销来适应 MS RFC 98:标签/文本呈现大修 提议的架构（虽然仍然不能支持复杂的文本塑造）。
作为一个矢量栅格，虽然速度稍快，但gd渲染质量远远低于对地图渲染器的预期。
1.3当前GD强度¶
GD图像缓冲区具有较低的内存开销，因为它们使用8位像素而不是32位像素。
GD支持不带消除混叠的渲染-适用于矢量区域填充（避免沿“平铺”边界的细线）。
2。GD支架拆除¶
除了防止 MS RFC 98:标签/文本呈现大修 要实现这一点，由于维护和渲染增强过程中所需的开销，对gd的支持已经在不断开发中。问题跟踪程序和邮件列表上的当前活动表明它未被积极使用。主要的7.0版本是完全删除GD支持的好时机，使我们能够进入可维护和可扩展的文本呈现管道，并使我们能够大大简化未来的维护。
2.1向后兼容性¶
在mapfiles中配置的gd输出格式将自动映射到agg/png8，即量化为256色png的agg渲染图像，正如当前禁用gd支持时所做的那样。最终生成的图像会有所不同。
仍在使用gd渲染器的用户的内存开销将增加。
三。投票历史¶
通过了托马斯布、汤克、米克斯、斯蒂芬、史蒂文、佩林、丹尼尔和杰夫姆的+1
4。跟踪问题¶
没有为此RFC创建任何特定问题。在内部跟踪发展 MS RFC 98:标签/文本呈现大修