Changes between Version 1 and Version 2 of MapGuideRfc52
- Timestamp:
- Jul 16, 2008, 12:32:36 PM (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
MapGuideRfc52
v1 v2 7 7 == Status == 8 8 9 ||RFC Template Version|| (1.0)||9 ||RFC Template Version||1.0|| 10 10 ||Submission Date||July 16, 2008|| 11 11 ||Last Modified||Walt Welton-Lair [[Timestamp]]|| … … 24 24 == Overview == 25 25 26 This section brefly describes the problem set, and the proposed solution in general terms. It should be deliberately short, a couple of sentences or so.26 !MapGuide currently has two image-based renderers: GD and AGG. AGG was added in Fall 2008 with [wiki:MapGuideRfc32 MapGuide RFC 40], and is now the preferred image renderer. There is no good reason to continue supporting the GD renderer. 27 27 28 28 == Motivation == 29 29 30 This is the most important part of the RFC. It describes the problem domain in detail. Focusing on this will allow reviewers to fully understand why the proposed change is being made, and potentially suggest different/better ways of accomplishing the desired results. The more time we spend on understanding the problem, the better our solution will be. 30 The GD renderer was !MapGuide's initial image-based renderer. While it did a good job, the AGG renderer now provides superior image quality, especially when it comes to anti-aliasing. The AGG renderer is now also mature in terms of stability and performance - it currently has no open issues. For this reason AGG is configured as !MapGuide's default image-based renderer. 31 32 One of GD renderer's biggest issues is that it doesn't provide full support for the new stylization ([wiki:MapGuideRfc32 MapGuide RFC 14]). In particular it does not support clipped area styles. While support for this could be added, it seems like a waste of time given that AGG already fully supports the new stylization ''and'' provides better image quality. A recent RFC around raster reprojection ([wiki:MapGuideRfc32 MapGuide RFC 51]) also raised the issue as to whether GD renderer would need to be updated. 33 34 From a SWD point-of-view it's clearly more work to support both AGG and GD renderer. AGG is the renderer we are pushing going forward, and SWD effort should be spent improving it and not GD. 31 35 32 36 == Proposed Solution == 33 37 34 This is a more detailed description of the actual changes desired. The contents of this section will vary based on the target of the RFC, be it a technical change, website change, or process change. For example, for a technical change, items such as files, XML schema changes, and API chances would be identified. For a process change, the new process would be laid out in detail. For a website change, the files affected would be listed. 38 Removing GD renderer will be simple. It involves deleting a couple of source files in the Renderers project, and removing support for the "Renderer" setting under "!GeneralProperties" in the serverconfig.ini file. 39 40 Note that we can't remove the GD library from the Oem area, since AGG renderer still uses it for read/write support of JPG/GIF/PNG8 images. 35 41 36 42 == Implications == 37 43 38 This section allows discussion of the repercussions of the change, such as whether there will be any breakage in backwards compatibility, if documentation will need to be updated, etc. 44 After this change, any !MapGuide server which was configured to render using GD will now only render using AGG. 45 46 This will have a slight impact on partial tile sets which were generated using GD. If the server is updated and the tile sets are migrated, then the existing tiles will continue to be served up, while any new tiles which are generated will be done using the AGG renderer. This will cause slight discrepancies at boundaries which have a GD tile on one side and an AGG tile on the other. The workaround is to regenerate the tile set using AGG. 39 47 40 48 == Test Plan == 41 49 42 How the proposed change will be tested, if applicable. New unit tests should be detailed here??? 50 The code that will be updated to remove support for the "Renderer" serverconfig.ini setting will be tested. No changes / additions to unit tests will be necessary. 43 51 44 52 == Funding/Resources == 45 53 46 This section will confirm that the proposed feature has enough support to proceed. This would typically mean that the entity making the changes would put forward the RFC, but a non-developer could act as an RFC author if they are sure they have the funding to cover the change.54 Provided by Autodesk.
