Graphics Library for D

[Adam Wilson]

On Sun, 05 Jan 2014 21:32:54 -0800, Mike <none at 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