Difference between revisions of "Canvas"
(→Introduction) |
(→Introduction) |
||
| Line 5: | Line 5: | ||
In contrast, the Canvas offers a contemporary set of features useful for rendering application content, including ubiquituous alpha, floating point coordinates, texturing, and advanced text layouting facilities. Where VCL OutputDevice is a concrete class (without any virtual methods), the Canvas consists of a set of UNO interfaces grouped around the central [http://api.openoffice.org/docs/common/ref/com/sun/star/rendering/XCanvas.html com::sun::star::rendering::XCanvas] interface. | In contrast, the Canvas offers a contemporary set of features useful for rendering application content, including ubiquituous alpha, floating point coordinates, texturing, and advanced text layouting facilities. Where VCL OutputDevice is a concrete class (without any virtual methods), the Canvas consists of a set of UNO interfaces grouped around the central [http://api.openoffice.org/docs/common/ref/com/sun/star/rendering/XCanvas.html com::sun::star::rendering::XCanvas] interface. | ||
| + | [[Image:Canvas_architecture-thumb.png|left|200px|The Canvas Architecture. Click on image for full view]] | ||
Because Canvas is interface-based, it's easy to provide multiple implementations, even for the same platform, and switchable during runtime (VCL does that during compile-time, depending on the platform it is built for). | Because Canvas is interface-based, it's easy to provide multiple implementations, even for the same platform, and switchable during runtime (VCL does that during compile-time, depending on the platform it is built for). | ||
To facilitate easier migration, one of the Canvas implementations is based on VCL. Thus, every platform that has VCL working automatically gets a working Canvas - important to reduce effort for new ports, e.g. the MacOS Aqua port. Later on, these platforms might consider providing a native XCanvas implementation. | To facilitate easier migration, one of the Canvas implementations is based on VCL. Thus, every platform that has VCL working automatically gets a working Canvas - important to reduce effort for new ports, e.g. the MacOS Aqua port. Later on, these platforms might consider providing a native XCanvas implementation. | ||
| Line 35: | Line 36: | ||
AW's recent drawing layer fixups also make use of it), which | AW's recent drawing layer fixups also make use of it), which | ||
resides in /graphics/basegfx. | resides in /graphics/basegfx. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==Module structure== | ==Module structure== | ||
Revision as of 23:01, 3 March 2008
Introduction
Starting for OOo 2.0, the Canvas effort tries to modernize OOo's graphical output layer - its predecessor, VCL's OutputDevice, carries the burden of being designed as a shallow wrapper around Win16 GDI. Back in the day, everything was integer coordinates, bezier curves didn't exist, nor a notion of alpha.
In contrast, the Canvas offers a contemporary set of features useful for rendering application content, including ubiquituous alpha, floating point coordinates, texturing, and advanced text layouting facilities. Where VCL OutputDevice is a concrete class (without any virtual methods), the Canvas consists of a set of UNO interfaces grouped around the central com::sun::star::rendering::XCanvas interface.
Because Canvas is interface-based, it's easy to provide multiple implementations, even for the same platform, and switchable during runtime (VCL does that during compile-time, depending on the platform it is built for). To facilitate easier migration, one of the Canvas implementations is based on VCL. Thus, every platform that has VCL working automatically gets a working Canvas - important to reduce effort for new ports, e.g. the MacOS Aqua port. Later on, these platforms might consider providing a native XCanvas implementation.
Currently, there are seven Canvas implementations in varying levels of completeness:
- Java-Graphics2D-based
- VCL-based
- cairo-based
- X11 backend
- Windows backend
- Aqua backend
- DirectX/GDI+-based
and one empty demo implementation (nullcanvas), that can serve as a template for new ports.
For migration purposes, the new Canvas and VCL's OutputDevice will be contained in OOo for quite some time, allowing a step-by-step adaptation of the applications. Therefore, the canvas and VCL must somehow interoperate, since new code, using the canvas, typically is embedded in a VCL-based environment (for example, the OOo windows are still provided by VCL. To render into such a window via the canvas, a canvas must be constructable from a VCL window). Thus, essentially two new methods are provided at VCL's window, namely Window::GetCanvas() and Window::GetFullScreenCanvas(). Apart from that small link, canvas and VCL are completely separated.
The canvas framework currently consists of the following CVS modules, /gsl/canvas and /gsl/cppcanvas. Additionally, a new generic graphics tooling is used (but not exclusively by the canvas, AW's recent drawing layer fixups also make use of it), which resides in /graphics/basegfx.
Module structure
- canvas/
- inc/
- canvas/ Public canvas headers
- base/ Base classes and template wrappers for XCanvas-implementors
- rendering/ Interfaces for a software render suitable for XCanvas
- canvas/ Public canvas headers
- prj/ usual build system boilerplate
- source/
- cairo/ The cairo-based canvas implementation
- directx/ The DirectX/GDI+-based implementation
- factory/ A Canvas factory, allowing smart fallbacks and user configuration (e.g. for the hw acceleration checkbox)
- java/ A Java-Graphics2D-based implementation
- null/ A dummy implementation that renders nothing, but contains all the plumbing to successfully fake a canvas for OOo
- simplecanvas/ A wrapper around XCanvas, providing old-skool procedural rendering functions
- tools/ Common tools shared among c++ canvas implementations
- vcl/ The VCL OutputDevice-based implementation
- workben/ a little demo app exercising the Canvas
- inc/
