Graphics Library for D

[Mike Parker]

On 1/8/2014 5:35 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang at gmail.com>" wrote:
> On Tuesday, 7 January 2014 at 20:06:47 UTC, Adam Wilson wrote:

>
>> counts for quite a bit. His biggest point however is that the
>> high-level API should be completely independent of the low-level API's.
>
> That's not possible. The GPU pipeline defines a design space. For 2D
> graphics it consists of texture atlases, shaders and how to obtain
> "context coherency" and reduce the costs of overdraw. If you stay in
> that design space and do it well, you get great speed and can afford to
> have less efficient higher-level structures creating a framework that is
> easier to use. The more low level headroom you have, the more high level
> freedom you get.

It is very much possible. There are a number of high-level graphics APIs 
out there designed in just such a way, many of which predate shader 
APIs. Java2D is a prominent one. For the sort of package we're 
discussing here, you should never define the high-level API in terms of 
low-level API features. Shaders shouldn't even enter into the equation. 
That's the sort of backend implementation detail that users of the API 
shouldn't have to worry about.

What you're talking about is fine when you have the luxury of supporting 
a limited number of platforms, or are working in a specific application 
space (games, for instance). In those cases, performance is going to 
trump generality and you can model your API more closely to the 
hardware. But for a general-purpose graphics API that needs to be 
available on as many devices as possible, that's not going to work. And 
anything that's going to be considered for inclusion into Phobos 
probably should favor generality over performance. Ideally, the default 
backend should be software, so that the API can be used even when 
graphics hardware is not available (though I'm not saying that's a 
realistic target to start out with).

I realize that we're in an age where GPU programming is becoming more 
common and even cell phones have good hardware acceleration, but another 
consideration is the target audience. If you want an API that a 
non-graphics programmer can more easily get up to speed with, then 
that's another reason that you can't let the low-level influence the 
design. The closer you get to the details, the more difficult it is to 
learn.

It's quite possible to put together a reasonably performant, 
easy-to-use, general purpose graphics API that can take advantage of the 
best renderer on a given platform without letting the low-level details 
leak into the high-level design.