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.
