MS RFC 99: Remove support for GD renderer¶
- Date:
2013/06
- Author:
Thomas Bonfort
- Contact:
- Status:
Adopted
- Version:
MapServer 7.0
1. Summary¶
Keeping support for the GD rendering library is preventing MapServer from moving onto a more feature-full and maintainable text/labeling pipeline. This RFC proposes that we remove support for the GD renderer in the upcoming 7.0 release, unless there are some use-cases only covered by GD that have been overlooked, and/or someone is sufficiently interested to fund the high maintenance overhead.
1.1 History¶
The GD library was initially the only renderer supported by MapServer for producing bitmap images (i.e. for png, jpeg and gif outputformats).
At the cost of major code duplication, support for SVG, PDF and SWF were later added.
In 2007, again at the cost of another major code duplication, AGG support was added, with some non-trivial issues when trying to work along with GD’s proprietary internal pixel reprensentation.
In 2011, for the 6.0 release, a major rewrite of the rendering engine occurred in order to cut down on the maintenance issues that had arose due to the previous code duplications. Already at that time dropping support for GD was discussed, but was finally kept for 8bit modes only at the cost of a higher worload on the maintainers. At the same time, AGG became a central component inside the mapserver library, and was used for some rendering tasks not supported by other renderers.
In 2012, for the 6.2 release, support for GD became optional and could be disabled at compile time.
1.2 Current GD limitations¶
In the process of supporting advanced text/label rendering implied by the overhaul of MS RFC 98: Label/Text Rendering Overhaul, the limitations of the GD api have shown to be a showstopper for moving forwards. Keeping support for GD would require either maintaining the current text rendering pipeline alongside the new one (at the cost of maintenance nightmares), or a non-trivial overhead to fit in with the MS RFC 98: Label/Text Rendering Overhaul proposed architecture (while still not being able to support complex text shaping).
As a vector rasterizer, while being marginally faster, the GD rendering quality is far from what is expected from a map renderer.
1.3 Current GD strengths¶
GD image buffers have a lower memory overhead, given they work with 8bit pixels instead of 32bit ones.
GD support rendering without anti-aliasing - good for vector area fills (avoids thin lines along the « tile » boundaries).
2. GD support removal¶
Aside from preventing MS RFC 98: Label/Text Rendering Overhaul to happen, support for GD is already himpering development due to the overhead required during maintenance and rendering enhancements. Current activity on the issue tracker and mailing lists show that it is not being used actively. The major 7.0 release is a good time to remove GD support entirely, enabling us to move onto a maintainable and extensible text rendering pipeline, and allowing us to greatly simplify future maintenance.
2.1 Backwards compatibility¶
GD outputformats configured in mapfiles will silently be mapped to AGG/PNG8, i.e AGG rendered images quantized down to 256 color pngs, as is done currently when GD support has beend disabled. The final resulting images will differ.
Memory overhead for users still using the GD renderer will augment.
3. Voting History¶
Passed with +1 from ThomasB, TomK, MikeS, StephanM, SteveW, PerryN, DanielM and JeffM
4. Tracking Issue¶
No specific issue was created for this RFC. Development was tracked inside MS RFC 98: Label/Text Rendering Overhaul