Graphics Library for D

[Mike Parker]

On 1/8/2014 9:59 PM, Jacob Carlborg wrote:
> On 2014-01-08 12:34, Mike Parker wrote:
>
>> Perhaps. But I would argue that if you need that sort of access then you
>> should be using a more specialized library anyway. I'm under the
>> impression that what we're discussing here is something simple and easy
>> to use. That can cover a wide range of use cases without accessing the
>> low level, but would be an impedement if you do need the low level.
>
> The question is how much you're gaining by hiding it.
>

The first thing that comes to mind is protecting render state. If you 
expose the low-level details, you give the user the ability to change 
the render state. This is a big deal in OpenGL, given its state-based 
nature (though less so with 4.x as I understand it). If you expose that, 
then that means the backend has to constantly set and reset state in 
case the user has done anything independently, impacting performance for 
the majority of people who don't need that low-level access. As long as 
its hidden, then the implementation can manage state changes more 
efficiently. Unless, of course, you don't expose the lowest level 
(OpenGL) but instead wrap state management in an interface that you 
expose. Now, you've added complexity to your interface just for a small 
subset of users. This becomes a big deal when implementing and 
maintaining multiple backends.

I really feel that a graphics API should choose between simplicity and 
power (high performance, custom special effects). This can help 
streamline the API and make design decisions in the interest of the 
target group. Trying to support both is only going to result in an API 
that's possibly harder to use and certainly more difficult to maintain.