Better late than never. ;-)
Unified 2D graphics subsystem for Dojo
A realistic graphics subsystem should implement 6 major components:
* Graphics Context – a container for graphics, which implements
* Shapes – a set of basic geometric shapes. The most basic shape is a
path. One important concept is a group of shapes.
* Fill – a way to fill in a shape. The most basic fill is a solid
color fill. A pattern is a more generic fill. Linear and radial
gradients are useful too.
* Stroke – a way to stroke a shape. The most basic stroke should
accept a color and a line width. Fancier styles include a pattern-based
stroke, a line cap style, and line join style.
* Transformations – a way to transform shape’s geometry before actual
Fill, stroke, and transformation are separated as concepts because they
can be applied to different shapes, or reused in some other way. This is
a common scenario for many drawings.
Advanced facilities include:
* Image operations – image-specific interpretation, composition,
transformations, filters, and so on.
* Text operations. For example, generation of paths with a text
string, selection of a font.
* Clipping – using shapes to clip drawings.
* Additional adornments like automatic shadows, and such.
Current state of affairs
At this moment we have 3 vector-based APIs on the market: SVG, VML,
Canvas. SVG is supported natively by FF1.5 and Opera9, VML is supported
natively by IE, Canvas is supported natively by FF1.5, Opera9, and
SVG and VML define a markup language, while Canvas is provided as a
to draw pretty pictures: created objects can be modified on the fly,
events (like, onclick) can be attached to provide easy interactivity.
The idea is to define a generic API, which can be effectively
implemented in a renderer in terms of native APIs. This API can be used
by graphics widgets written in generic manner, which can be used in any
supported environment transparently. Clearly such API is going to be
simpler than underlying APIs. GCD functionality can be implemented
directly by all renderers. More advanced functionality can be
implemented using fallbacks.
Additional requirement is to come up with a markup, which can be used
inline independently of used renderer.
Given the current situation following functionality can be implemented
more or less uniformly across existing graphics APIs: graphics context
(surface), shapes (path, rectangle, polyline, ellipse, arcs, bezier),
fill (solid color, linear gradient, image pattern), stroke (color, line
width, line caps, line joins), transformation (translate, rotate,
scale), image primitive, state stack manipulations (save, restore).
State includes current values of transformation, fill style, and stroke
Everything goes into a new package dojo.gfx (we can debate name later,
e.g., it can be placed in the existing dojo.graphics).
By necessity the API is heavily influenced by Canvas API --- the most
Global package-level functions
dojo.gfx.createSurface(parentNode, width, height, [renderer])
It creates a new surface for a picture. It corresponds to