Skip to content

Refactor vector drawing code to a renderer subsystem #155

Closed
@florianf

Description

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions