One of the questions to be answered is how we handle 3-d
> axes and their labeling. I doubt (John may differ on this)
> that we want to go into fancy 3-d character sets and such,
> but it may be possible to do simple transforms on fonts to
> make them look like they lay on the appropriate plane.
Now that we can get the glyph vertices from agg/freetype, transforming
them with a 4x4 matrix should be easy enough.....
We've spent a lot of time talking about how to implement 3D (vtk,
opengl, do the work ourselves in software and render it in 2D) but I
am beginning to think this is the wrong discussion. We should just
provide the front-end infrastructure which holds the data and
transformations (Axes3D, Line3D, Poly3D, etc) and then let different
3D engines/backends handle the rendering, just as we do for 2D. Of
course, one nuance is that the 3D renderer must render into the canvas
which may also have 2D stuff in it, but I think this could be done via
a bitmap transfer as Randy did for his proof-of-concept VTK/Agg demo,
with an acceptable performance cost for most uses. The basic idea is
that I don't think we need to commit to a 3D engine, we just need to
set up the frontend API correctly.
We should probably write up a semi-official pep for discussion, just
to make sure the ideas are solid. Andrew has started on such a beast
but has yet to let anyone see it 
One open question is do we define new primitive types (Line3D, Poly3D,
Text3D)? Doing so has the advantage of leaving the tried and true 2D
stuff alone and does not impose extra memory or performance costs on
the 2D side. But it creates multiple points of maintenance, etc...
Another question: would it suffice to simply add a few new methods to
the backend renderer, draw_line3d to complement draw_line,
draw_polygon3d to complement draw_polygon, and so on. One might be
able to then create mixin renderers, composing agg with say pyopengl
to provide the 2D and 3D rendering respectively. Somehow this seems
too easy, so it must be a stupid idea.
JDH