DirectFB 2.0: A new accelerated rendering core (new driver interface)

From DirectFBWiki

The new DirectFB core rendering and driver design will follow the higher level goals of create a well defined core api for systems programmers with api's available as loadable modules. The primary target application level api's are Water, Cairo and OpenVG.

Initially we will follow the path outlined in Cairo Support but a move toward pluggable tessellation is a longer term goal of the DirectFB 2.0 project.

In cases such as a vendor provided OpenVG implementation DirectFB would simply pass through the api for supported surfaces.

One of the important goals of the core framework is to expose and standardize a low level system api to allow multiple api support. The advanced 2D api's are probably the most challenging aspect of the new design.

To solve this problem the 2D architecture will follow a compiler design strategy. For 2D this consists of three main components.

• High Level abstract drawing commands consisting of paths, resources, context information etc.
• Conversion of paths to primitive form i.e tessellation (http://en.wikipedia.org/wiki/Tessellation#Tessellations_and_computer_graphics)
• combining the low level pixel path and drawing commands to paint pixels.

With two types of inputs paths and path operations. Path operations such as filling and stroking are basically passed through to the core thus the focus is on converting paths to the best form for the core driver. The rendering core will focus on supporting tesselators and low level simple path representation.

For example given the high level path api of cairo we need to define the following.

Tesselator front end with cairo path definition binding. Tesselator output format mapped to the best representation for the driver. The reason for moving the tessellator into the driver is simple. The way the tessellator works depends on the underlying hardware.

• GPU avalability
• Floating Point Support and performance
• Quality of output
• Antialiasing

By designing both to support multiple tesselators and public primitive formats we should be able to obtain excellent performance with flexibility.

The low level or primitive format is defined to be the same as the public WaterBasicElement (http://www.directfb.org/docs/Water/draft/types.html#WaterBasicElement)

Cairo Implementation Example

For the cairo api a implementation approach for path stroking would be as follows.

For tesselation we would make the entry point similar _cairo_path_fixed_stroke_to_traps which is defined in cairo-path-stroke.c

 cairo_status_t
 _cairo_path_fixed_stroke_to_traps (cairo_path_fixed_t   *path,
                                    cairo_stroke_style_t *stroke_style,
                                    cairo_matrix_t       *ctm,
                                    cairo_matrix_t       *ctm_inverse,
                                    double                tolerance,
                                    cairo_traps_t        *traps)

But in our case we would have one of these core functions per WaterBasicElementType.

On the driver side the driver would publish the WaterBasicElementType it supports. In addition we would need conversion tesselators that convert from one basic type to another. Rendering quality should probably be included at this level.

For cairo the changes are minimal we simply add this higher level hook and the current tesselator becomes a fallback similar to the cairo image/pixman rendering backend.

With the current cairo implementation this means that function pointer hooks for stroking which need to be checked in the functions: _cairo_gstate_stroke_extents _cairo_gstate_in_stroke

We already have a hook with fallback in _cairo_surface_stroke so its not a major change to move to a fully pluggable tesselator. Of course a more exhaustive review is needed and fill is similar but in principle for cairo providing alternative tesselators is not difficult using the current fallback design of cairo.

Using the new API

In many ways this api is similar to the surface pool concept but now we have a pool of tesselators and tesselator output handlers. For stroking we have three basic functions stroking the path, extents or enclosing rectangle for the path and determining if a point is inside or on the path or hit testing.

DirectFB would have a pool of tesselators and driver requirements for best output. In the simple case of dumb frame buffer we would probably just fallback to cairo's builtin tesselator or provide a software equivalent that could for example take advantage of a floating point unit. The next extreme would be OpenVG which would directly provide the three functions needed. In between the two cases DirectFB would determine the best combination of tesselator and supported primitive format for the request.