Fitz: A New Foundation for 2D Graphics
Motivation
- scalable vector graphics are popular, and getting moreso.
(c.f: PostScript, PDF, Flash, Java2D, Quartz, SVG)
- resolution / display dependence of GDK / Xlib are an embarassment
- We'd like to use a resolution-independent foundation for GUI toolkits.
- unfortunate disconnect between on-screen and printed output.
- no freely available 2d graphics library or standardized API
- high-quality, hinted, anti-aliased fonts a requirement.
- future: scenegraph-based user interfaces (Jazz)
Goals / Requirements
General
- Provide a standard API that enables applications to describe high quality,
resolution-independent vector-based images for either printed or on-screen
display.
- Efficient support for animation, by enabling the
application to (conceptually) specify updates to a scene representation.
Imaging Model
Fitz will provide the complete PDF 1.4 imaging model, with the
(temporary) exception of In-RIP Trapping. Specifically:
- Seamless support for images as well as vector-based
scenes.
- Image composition with transparency / alpha-blending.
- Support for high-quality, scalable outline fonts, possibly employing sub-pixel positioning,
hinting, and/or anti-aliasing, as appropriate.
- Non-rectangular clipping: It must be possible to use any shape to
clip another shape or image.
Rendering Portability
- The implementation must allow multiple back-end renderers, and
must allow an application to use multiple renderers from within a
single application. Some obvious examples of back ends are:
- Pixmap-Direct - renders directly onto an RGB or RGBA pixmap
- PostScript and PDF file writers
- XRender
- GDI+
- Quartz
- Java2D
For performance reasons, the back-ends for proprietary 2D rendering APIs
should attempt map high-level Fitz operations to their counterparts in the
proprietary API whenever possible.
However, when the differences in the library interfaces make
this impractical, it is expected that such renderers will fall back to
raster-based rendering.
- Support for both immediate mode and display list drawing. Immediate
mode offers more low-level control, but display lists offer more
opportunities for optimization.
Runtime Portability
- It should be possible to use Fitz from within single-threaded,
event-based GUI toolkits, such as Gtk+.
- It should be possibe to use Fitz in systems where true
user- or kernel-level threads are available, and to perform
rendering in one or more threads that are
separate from the main application thread.
Font Support
- Attribute-based font selection mechanisms that enable
applications to be written that are guaranteed to be
portable to any back-end renderer implementation.
[Raph: Hmm. This one is complicated. It's certainly useful to
applications, but is massively platform-specific. Perhaps there
should be a platform-independent "Fitz core", plus other stuff.
To render PDF well, you want to be able to substitute fonts
intelligently. Here, the big challenges are encoding differences
and width-munging (having good, free multiple master fonts would
help a lot on the latter point).]
- (Somewhat converse to the previous point): Enable an application
to precisely specify particular fonts, with the caveat that specific fonts
may not be available on all platforms or renderers.
Geometry
- Precise Bounds Calculations: The implementation must be able to
provide the application with a precise bounding rectangle for any
scene or part of a scene.
- Conservative Region of Interest calculations: When objects change
or otherwise need to be redrawn, the implementation must provide the
application with a region containing at least all changed
pixels. Libart's microtile arrays are a good basis for this functionality.
- Constructive Area Geometry: The implementation must provide
mechanisms for construction of closed shapes from sequences of
straight or curved segments, and allow arbitrary composition of shapes
via set-theoretic operations.
- Flattening / Iteration: The implementation must provide the
application with a means for obtaining complete information about the
outline of any constructed shape, either in flattened (i.e. consisting
only of line segments) or unflattened (i.e. using a combination of
straight and curved segments) form.
- Intersection Tests: The implementation must efficiently provide
tests to determine whether a shape intersects another shape, a
rectangle, or a point.
Output Device Portability
It should be possible to tune Fitz for a broad range of output
categories, including:
- Monochrome laser printers: 1 bit, no antialiasing, hinted font
rendering, ordered dithering.
- RGB displays: 8 bits per sample, aa by default, unhinted font
rendering by default).
- Inkjet printers: around 2 bits per sample (post-dither, at least
8 pre-dither), complex color management (6 inks or more common),
error diffusion dithering. The value of aa is probably
res-dependent (at 360 dpi, it might be very nice, but at 720
dpi, not visible).
- Imagesetters: 1 bit per sample, no aa, ordered dithering with
precise angles. Again, font hinting is probably irrelevant because
of the high resolution.
Performance Goals
- Fast rendering speed. Defining this precisely requires nailing
down the types of images that will be rendered, the target platform
particularly, acceleration), and more.
- Minimal memory consumption. This will be especially important
when embedding into printers and other limited-resource targets.
Rendering Quality
The implementation must provide topnotch rendering quality, including:
- Subpixel positioning of text, especially when aa and unhinted.
- All color transforms within tight error bounds.
- High quality image interpolation (lower quality, but quicker,
modes can also be provided).
- 16 bit deep output as an option.
- Gradients rendered without bands or other visible artifacts.
- Correct "stroke adjustment" in non-aa modes.
- "Exact" antialiasing as an option. This removes the seam when
alpha-compositing two abutting objects.
- High quality dithering - Even Better Screening for inkjets,
Well Tempered Screening for 1 bit devices, and probably a 16 bit
to 8bit reducer (similar to GdkRgb's) capable of rendering
absolutely step-free gradients.
Architecture
Tree access API, asynchrony, compositional geometry API, etc...
...should lead to an API specification.
Open Questions
Related Work
People