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