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.
