Graphics Library for D

[Adam Wilson]

On Tue, 07 Jan 2014 23:52:48 -0800, Jacob Carlborg <doob at me.com> wrote:

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

As useful as that may be I want to keep the scope focused for now. A  
high-level API allows us the most flexibility in terms of implementation  
and user accessibility. We're not trying to be triple-A performant so  
building out extra API levels for more performance is a low priority.  
Let's do something focused and do it well before we expand the scope. This  
project is already huge. :-)

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


-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator