On Sun, 05 Jan 2014 21:32:54 -0800, Mike <n...@none.com> wrote:
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.
That's the plan. However at this point D only works on x86 so it's a moot
point. But if we built a pluggable rendering backend that would allow us
to swap the rendering that should be sufficient.
* Please consider more than mouse and keypboard as input devices (e.g.
multitouch)
Definitely. I included touch on my list because even outside the
phone/tablet market it can be useful. All my desktops have a touch monitor.
* 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.
I've heard of it, and we are definitely open to stealing the best of any
library, so I/we take a look at it.
* 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.
This is a good idea, I like it.
* The rendering engine should be its own library/package, that
should be easily replaced with whatever is suitable for the given
platform.
As in pluggable backend? That should be easy enough to do.
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.
Combined with the above idea this would be an excellent demonstration of
D's capabilities. And it would definitely improve the design of the
library.
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)
The problem I can see here is that if you want to test the first four,
number five has to be built out to some degree.
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.
Indeed, a graphics library is required for my future plans as well. Which
is why I am speadheading this project. :-)
But, please play a little with AGG before you begin your design. I
think you'll be glad you did. (http://www.antigrain.com/)
--
Adam Wilson
IRC: LightBender
Aurora Project Coordinator
