DConf 2014 Day 2 Talk 3: Designing an Aurora: A Glimpse at the Graphical Future of D by Adam Wilson

[Tofu Ninja via Digitalmars-d-announce]

On Tuesday, 8 July 2014 at 16:03:36 UTC, Andrei Alexandrescu
wrote:
>http://www.reddit.com/r/programming/comments/2a5ia9/dconf_2014_day_2_talk_3_designing_an_aurora_a/

Great talk but I have some reservations about the design. What I
am most concerned about is the design of the immediate mode
layer. I was one of the few who initially pushed for the
immediate mode but I think you missed the point.

There are several points that I want to address so I will go
through them one at a time. Also I apologize for the wall of text.

*Scene Graph
Personally I find it odd that the immediate mode knows anything
about a scene graph at all. Scene Graphs are not an end all be
all, they do not make everything simpler to deal with. It is one
way to solve the problem but not always the best. D is supposed
to be multi paradigm, locking the users into a scene graph design
is against that goal. I personally think that the immediate mode
should be designed for performance and the less performant but
'simpler' modes should be built on top of it.

*Performance vs Simplicity
I know that you have stated quite clearly that you do not believe
performance should be a main goal of Aurora, you have stated that
simplicity is a more important goal. I propose that there is NO
reason at all that Aurora can't have both in the same way that D
itself has both. I think it is just a matter of properly defining
the goals of each layer. The retained mode should be designed
with simplicity in mind whilst still trying to be performant
where possible. On the other hand, the immediate mode should be
designed with performance in mind whilst still trying to be
simple where possible. The simple mode(s?) should be build on top
of the single performance mode.

*Design
Modern graphics hardware has a very well defined interface and
all modern graphics api's are all converging on matching the
hardware as close as possible. Modern graphics is done by sending
buffers of data to the card and having programmable shaders to
operate on the data, period. I believe that the immediate mode
layer should match this as close a possible. If that involves
having some DSL for shaders that gets translated into all the
other various shader languages then so be it, the differences
between them is minimal. If the DSL was a subset of D then all
the better.

*2D vs 3D
I think the difference you are making between 2D and 3D is
largely artificial. In modern graphics api's the difference
between 2D and 3D is merely a matrix multiply. If the immediate
mode was designed how I suggest above, then 2D vs 3D is a non
issue.

*Games
D is already appealing to game developers and with the work on
@nogc and andrei's work with allocators, it is becoming even more
appealing. The outcome of Aurora could land D a VERY strong spot
in games that would secure it a very good future. But only if it
is done right. I think there is a certain level of responsibility
in the way Aurora gets designed that needs to be taken into
account.


I know that most of my points are not in line with what you said
Aurora would and wouldn't be. I just don't think there is any
reason Aurora couldn't achieve the above points whilst still
maintaining it's goal of simplicity.

Also, I am willing to help, I just don't really know what needs
working on. I have a lot of experience with openGL on windows
writing high performance graphics.