Graphics Library for D

[Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>]

On Wednesday, 8 January 2014 at 13:09:39 UTC, Mike Parker wrote:
> I could have sworn I read somewhere in this thread that there 
> was talk of including it in Phobos at some point. That's the 
> perspective I've been arguing from. If it's fully intended to 
> be separate from Phobos, then there's no need for any of this 
> and the feature list could certainly be more specific.

Well, the goals are very unclear to me, but I guess this 
discussion and the friction between differing assumptions will 
sort out what belongs in a standard library :-)

 From my perspective Phobos should only provide building blocks 
that are generally useful for many different applications. I 
don't think a real time graphics engine belongs in the standard 
distribution. Real time engines tend to be short lived.

I think the basic setup for each platform belongs there. The same 
tedious stuff that most apps on a platform have to deal with in 
order to get started with real time stuff. Once you have a GL/DX 
context on your hands you can get application stuff going in D 
with C bindings and a sample application (graphical hello world) 
would probably be better than a complete framework.

> I wouldn't expect any implementation, generic or otherwise, to 
> assume mostly static geometry. You could bet that a simple 
> graphics API in Phobos would be used for games by some and for 
> generating pie charts by others. It's still possible to get a 
> generic rendering system to handle that with decent 
> performance. Yes, it makes for compromises in the backend that 
> a more targeted renderer wouldn't need to make, but that's the 
> price of genericity.

2D games, web browsers etc use geometry that is mostly static 
between frames (although it can be hidden). So you can cache and 
have a dirty-flag on each surface (if the path-data change you 
set the dirty flag and the engine recreates the cached surface). 
3D is different because of the perspective effect which force you 
to a complete redraw every frame.

> This is true. But assuming a) the library is going to be in 
> Phobos and therefore b) there is going to be a software 
> backend, and c) there's a desire for feature parity between the 
> software renderer and any hardware-accelerated backends, then 
> custom shaders increase the complexity of the software 
> implementation quite a bit. There are so many rules needed to 
> guide the implementation in terms of render quality. Ugh!
>
> That's a lot of assumptions, I know. If this is not going to be 
> in Phobos and there's no pressing need for a software renderer 
> then it's moot. In that case, the sky's the limit.

I think you can have the building blocks in Phobos:

1. A path datastructure that can be used for vector path 
manipulation (fully SVG/postscript/PDF compatible). Useful both 
for rendering and if you want to do editing/transforms of file 
formats etc.

2. A simple D-compatible shader language with parser and ability 
to generate common shader languages (also the the non GL/DX ones 
used by various multimedia applications for movie effects). The 
shader language could be this simple:

"r=src1*0.4; g=src1*0.2; b=src1*0.8; a=1.0;"

It could be so simple that you could embed it in your D rendering 
loop verbatim, as D code.

3. A software path based renderer in D that generate image masks 
that use (1++) as input.

4. A software compositor that can generate PNG and PDF based on 
(1) and (2), and SVG if you only use builtin shaders (the fill 
types supported by SVG).

5. A portable 2D compositor framework, that basically takes 
byte-masks from any source (could be a vector renderer) and 
images and compose them using very simple shaders.

Creating a compositor that performs well with many small objects 
is work though, because you need to maintain a texture atlas and 
heuristics for how to group etc…

You could probably configure a D-based compositor using 
templates, so I guess the hard part is figuring out what you need 
on the platform specific level to support a compositor written 
fully in D.

If you go the compositor route nothing prevents you from giving 
access to the GL/DX context, before/after the compositor is done 
rendering for those with advanced needs.

It is possible to implement 1,2 and 3 before designing 4 and 5. 
And at the end of the day 4 and 5 probably does not belong in the 
distribution, while 1,2,3 might.