On Tue, 07 Jan 2014 12:13:18 -0800, Ola Fosheim Grøstad
<[email protected]> wrote:
On Tuesday, 7 January 2014 at 19:31:38 UTC, Adam Wilson wrote:
True enough, but for the moment we are trying to keep the scope of the
project manageable. If someone wants to add it great! But until then we
need to focus on what is required.
Yes, that is true, and then we should define a set of applications which
it will be suitable for and what the basic model is: Should it be
immediate mode, retained mode or scene graph based?
I think Immediate Mode offers the greatest flexibility and performance.
It's also the easiest to implement since you don't have to build the
mountains of data structures needed to retain the scene info.
High level graphic frameworks tend to loose momentum fast, even the good
ones. Example: SGI's Open Inventor is actually a neat scene graph
framework, and open source, but dead. SGI's GL survived because it was
low level and immediate mode.
Cinder, Processing, etc are High-Level Immediate Mode, I think that offers
the best chance of succeeding.
So, I really think D is better off providing the basics in phobos first,
staying true to the virtue of providing independent modules that are
focused:
- OS application abstraction: graphics context, input stream, audio
playback
- generally useful vector path datatype compatible with
phobos-collections and SVG
- vector/matrix library with competitive SSE performance and features
such as clamping
To a large degree I agree with this. Getting some basics into Phobos is an
excellent idea and most of the community seems to agree. The biggest
problem I can see is that windows are usually tied to the graphics
framework the implements them. There are numerous reasons for that, all of
which make sense. For example, I don't know if it would be possible to
pass the Phobos window to Qt or DirectX, it might be, but we'll have to be
very careful in our API design if it is.
--
Adam Wilson
IRC: LightBender
Aurora Project Coordinator
