Canvas

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.

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). 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
  • 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