Graphics Library for D

[Jacob Carlborg]

On 2014-01-08 03:38, Mike Parker wrote:
> 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.

I would say that we should try and built the API in many different 
levels and layers. The top layer would be for ease of use to quickly get 
something to show on the display. If more performance is needed it 
should be possible to access the lower levels of the API to get more 
control of what you need to do.

> 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).

Ideally the default backend should detect if graphics hardware is 
available or not at runtime and choose the best backend for that.

> 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.


-- 
/Jacob Carlborg