[dojo-contributors] Re: Draft: Unified 2D graphics subsystem for Dojo

gavin at dfmm.org gavin at dfmm.org
Tue Jun 6 18:33:19 EDT 2006


OK, I've read Eugene's draft and everybody's comments. Here are what
thoughts I've been able to have during the family reunion this week.

Eugene's proposal is interesting in that he specifies a Canvas-style API
that returns DOM nodes which, presumably, can be manipulated futher and
serve as event sources. As he explains it, it's a retained-mode API
exposed as an immediate-mode API, which is pretty clever.

The excanvas library is similar in that it writes VML but is accessed via
the Canvas calls.

I think the reasoning is that we can implement shapes with the
lowest-level API, then layer structure atop them.

I still think I would want to be able to interact with an entity primarily
as a shape for something like the drawing editor I did with SVG
(http://www.xdraw.org/xdhTest.html for anybody catching up). It's very
natural to map shape properties onto node attributes. Implementing even
rudimentary shapes atop the actual Canvas/DirectAnimation API was more
work, particularly as DirectAnimation renders "backwards" from canvas
(http://www.xdraw.org/example_draw.html).

Perhaps we could use a "def" model with Eugene's API -- so you could
optionally do:

surface.beginPath({def: 'Square'});
// a bunch of drawing commands that define a square
var square = surface.endPath();
assert(square == null); // If defining, does not create the node
square = surface.createShape('Square');
assert(square != null); // The shape that would have been returned by endpath

The question here would be specifying available attributes in code.

Other random thoughts:

I like the idea of using an SVG subset and using client-side XSLT to
transform it to VML. That *ought* to get a picture into the browser faster
than interpreting it with javascript. We could then lazily instantiate
javascript objects from the generated DOM nodes as required for
interactivity.

It may really be the Wrong Thing, but I'd like to do some benchmarking and
prototypes to check -- I think there's a use for both Canvas-rendered
graphics as well as DOM-oriented graphics. That's why I investigated the
DirectAnimation api recently. It may be best to render some things one way
and some another. Worth a try, at least.

As far as transformations go, that was the latest thing I was working on
for the drawing editor. I was finding it mandatory to perform them myself
even for simple rotations -- I needed to do the matrix calculation both to
be able to specify the center of rotation and to calculate the positions
of the "handle" objects once the object they affect was rotated.

For v1 of the library, what's the order of use cases?

1) Generic, canvas-compatible drawing surface for charting and widgets
2) DOM-style drawing objects for editable shapes
3) Animation for cartoons and presentational effects
4) Text effects? (VML and SVG both support text effects that HTML DIV
elements cannot).

Gavin



More information about the dojo-contributors mailing list