Graphics Library for D

[Mike]

On Monday, 6 January 2014 at 07:17:05 UTC, Adam Wilson wrote:
> On Sun, 05 Jan 2014 21:32:54 -0800, Mike <none at none.com> wrote:
>> * 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.

I understand, but if I and others are able to achieve their 
goals, that's going to change soon.  It's not just about the 
backend, its about efficient use of resources and loose coupling. 
  For now, see if you can find a Pentium 166MHZ with 16MB of RAM 
for your testing.  If you can get it to run well there the 
Core-i7 users will also rejoice :-)

Of course I'm being a little silly, but please watch the 
following from Andei and Manu to see what I mean:
Expanding Platform Base 
(http://www.youtube.com/watch?v=4M-0LFBP9AU#t=2399)
Operational Professionalism 
(http://www.youtube.com/watch?v=4M-0LFBP9AU)
Memory Laziness 
(http://www.youtube.com/watch?v=FKceA691Wcg#t=2458)

>>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.
>
Allow me to elaborate more on why I think AGGs design is 
superior.  You don't actually have to port it to any platform.  
Because it uses templates, the porting is done with a few 
typedefs at the beginning of your program like so:

typedef agg::rgba8 Color;  //could be rgb8, bgr8, rgb16, rgb32, 
and many others
typedef agg::span_allocator<Color> SpanAllocator;
typedef agg::span_interpolator_linear<> SpanInterpolator;
typedef agg::rendering_buffer RenderingBuffer;
typedef agg::scanline_u8 Scanline;
typedef agg::rasterizer_scanline_aa<> Rasterizer; //aa is 
anti-aliasing, but could be aliased if you wanted.
typedef agg::path_storage Path;
typedef agg::conv_curve<AggPath> Curve;
typedef agg::conv_stroke<AggCurve> Stroke;

This configures the entire pipeline for my platform.  I didn't 
need to modify any header files, set and #defines, or add a if 
version(MyPlatform) block to the source code, etc...  Because its 
template programming, these new types will be compiled when I 
build, and I will have a custom rendering pipeline specific to my 
platform.  I didn't see how elegant this was at first, but now I 
think it's brilliant and really fulfills the promise of template 
programming.

You could probably use AGG to render an uncompressed Blue-Ray 
movie to ASCII art if you wanted to.

I don't suggest doing the same in D, necessarily, but I do 
suggest understanding this pattern and let it influence the way 
you approach portability.  There may even be a better D way that 
differs substantially from this.

>>   *  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.

A pluggable backend, yes, or possibly simply specifying a 
different template argument.

>>> 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.

Of course you are right.  I guess I was think more "fundamentals 
first".