Refactor vector drawing code to a renderer subsystem #155
Closed
Description
opened on Jun 22, 2011
Currently the logic for representing (domain object) and drawing a vector layer is bundled in the same class.
This makes some things hard to do, f.ex. drawing all shapes with a equal style in one canvas.stroke() / canvas.fill() operation. Every shape doesn't know anything about possibly other existing shapes. Also supporting different backends (canvas, svg, etc.) for vectors in one map seems a bit cumbesome.
Would it make sense to refactor the rendering code to a renderer subsystem, composed of the following parts:
- vector/renderer/RendererWrapper.js
Wrapper class that holds instances (if required) of all renderer backends. Listens for map events and delegates those events to the different renderer backends. Bundles rendering requests for special renderers, see canvas example mentioned above.
Has a addLayer(layer, prefferedBackend) method, that adds the Path to the concrete renderer, if available or uses a fallback. - vector/renderer/Renderer.js
Contains all general rendering code, event listener addition and removal, click detection, etc. - vector/renderer/Canvas.Renderer.js
Implements a cavnas renderer on supported platforms. Overrides one method from Renderer.js, f.ex. draw(). - vector/renderer/VML.Renderer.js
- vector/renderer/SVG.Renderer.js
Mostly the stuff which is now in the different Path.Canvas.js, etc. could be moved to the rendering subsystem.
Overhead? Drawbacks?
Activity