Difference between revisions of "DrawingPrimitives"
| Line 1: | Line 1: | ||
The DrawingLayer, i.e. the engine providing the Draw/Impress content, which is reused in both Calc and Writer, currently undergoes substantial refactoring. This rework takes place in [http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Id=3064&Path=SRC680%2Faw033 CWS aw033] (and partially in [http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Id=1999&Path=SRC680%2Faw024 CWS aw024]). Although the DrawingLayer was already usable as an engine, it had several shortcomings, among them no clear distinction between model and view (all model objects handled the viewing of their content themselves), lacking separation of concerns (lots of generally useful functionality was buried in the DrawingLayer code, instead of separated out into tooling libraries), and a hard-to-remove dependency on VCL's OutputDevice for rendering. | The DrawingLayer, i.e. the engine providing the Draw/Impress content, which is reused in both Calc and Writer, currently undergoes substantial refactoring. This rework takes place in [http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Id=3064&Path=SRC680%2Faw033 CWS aw033] (and partially in [http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Id=1999&Path=SRC680%2Faw024 CWS aw024]). Although the DrawingLayer was already usable as an engine, it had several shortcomings, among them no clear distinction between model and view (all model objects handled the viewing of their content themselves), lacking separation of concerns (lots of generally useful functionality was buried in the DrawingLayer code, instead of separated out into tooling libraries), and a hard-to-remove dependency on VCL's OutputDevice for rendering. | ||
| − | All three items will be addressed in [http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Id=3064&Path=SRC680%2Faw033 CWS aw033], and the means for that are DrawingPrimitives. The mental model for these primitives are metafiles, i.e. resolution-independent representation of renderable geometry. DrawingPrimitives define a hierarchy of increasingly simpler geometric primitives, starting with fairly high-level ones like customShapePrimitive or captionPrimitive, down to simple ones like polyPolygonColorPrimitive. | + | All three items will be addressed in [http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Id=3064&Path=SRC680%2Faw033 CWS aw033], and the means for that are DrawingPrimitives. The mental model for these primitives are metafiles or display lists, i.e. resolution-independent representation of renderable geometry. DrawingPrimitives define a hierarchy of increasingly simpler geometric primitives, starting with fairly high-level ones like customShapePrimitive or captionPrimitive, down to simple ones like polyPolygonColorPrimitive. The high-level primitives have built-in support for breaking them up into simpler ones, which makes implementing a renderer for DrawingPrimitives quite easy (in a first step, one has to provide only support for a small set of very basic primitives, like bitmap and polygon). |
Revision as of 11:44, 30 May 2006
The DrawingLayer, i.e. the engine providing the Draw/Impress content, which is reused in both Calc and Writer, currently undergoes substantial refactoring. This rework takes place in CWS aw033 (and partially in CWS aw024). Although the DrawingLayer was already usable as an engine, it had several shortcomings, among them no clear distinction between model and view (all model objects handled the viewing of their content themselves), lacking separation of concerns (lots of generally useful functionality was buried in the DrawingLayer code, instead of separated out into tooling libraries), and a hard-to-remove dependency on VCL's OutputDevice for rendering.
All three items will be addressed in CWS aw033, and the means for that are DrawingPrimitives. The mental model for these primitives are metafiles or display lists, i.e. resolution-independent representation of renderable geometry. DrawingPrimitives define a hierarchy of increasingly simpler geometric primitives, starting with fairly high-level ones like customShapePrimitive or captionPrimitive, down to simple ones like polyPolygonColorPrimitive. The high-level primitives have built-in support for breaking them up into simpler ones, which makes implementing a renderer for DrawingPrimitives quite easy (in a first step, one has to provide only support for a small set of very basic primitives, like bitmap and polygon).
