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.

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.

Canvas_architecture.png

The Canvas Architecture. Click on image for full view

XCanvas is part of bigger module in OpenOffice, called Drawing Layer. There is initiative to improve the whole module: Drawing Layer/Drawing Primitives

For XCanvas information, see presentations at OOoCon 2006 (PDF, ODP, video/ogg) and OOoCon 2005 (PDF)

Of the OOo applications using VCL, currently (September 2006) OOo Impress slideshow has been converted to XCanvas, with prototypes working in Draw and Impress. Future work will include converting Calc and Writer.

The location of the Drawing layer. Click on image for full view

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