I'm sure you'll receive no shortage of opinions with such an open
invitation, so here's mine:
* Please don't make a graphics library that is useful only on PCs.
* Please consider more than mouse and keypboard as input devices
(e.g. multitouch)
* Today is the first I've heard of Cinder, but if you really want
to see an extremely well-written graphics library, take a look at
AGG (Anti-Grain Geometry). It's is a superior example of
elegantly employed templates for a real practical problem (lot of
different platforms). As an example illustrating its reach, I
ported it to an ARM Cortex-M4 MCU at 168MHz with 2MB of RAM
trivial modification. It powers an 800x480 7" TFT LCD with
16-bit color and is damn fast. For a quick intro, go here
(http://www.antigrain.com/doc/introduction/introduction.agdoc.html#toc0006).
It is superior design model for anyone wishing to develop a
graphics library.
* Break the library into loosely coupled pieces that can be used
individually or aggregated by other projects to build things that
we haven't even thought of
* Geometric primitives should be their own library/package
* Vector graphics (paths, line caps, etc...) should be their
own library/package
* Raster graphics should be their own library/package
* Window management should be its own library/package
* Font's are just data. Don't couple them to the rendering
engine. (e.g Convert them to a vector/raster representation and
then let those libraries handle the rest.
* The rendering engine should be its own library/package, that
should be easily replaced with whatever is suitable for the given
platform.
I think Aurora should be a library of libraries that can be used
individually or aggregated to build new and exciting projects
that you and I haven't yet even thought of. Think std.algorithm.
The logical phases as I can see them are as follows, but please
suggest changes:
Start with the most primitive and move up from there (If loosely
coupled, the could be developed in parallel)
1. Geometric primitives
2. Vector graphics
3. Fonts (just a special case of vector graphics)
4. Rasterization
5. Backend (Direct2D/3D, OpenGL, OpenVG, whatever)
Once that is done, Widget libraries, Windowing, Input Device
handling, etc... can all be built on top of that.
A graphics library is something I will need in my future D plans,
so I look forward to seeing where this goes, and I hope I'll be
able to make a positive contribution or two myself.
But, please play a little with AGG before you begin your design.
I think you'll be glad you did. (http://www.antigrain.com/)
