Graphics Library for D

[Mike Parker]

On 1/8/2014 4:52 PM, Jacob Carlborg wrote:

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

It's only necessary to have an abstract renderer interface with concrete 
backend implementations at the lowest level. Then user-facing API 
(std.gfx.geometry, std.gfx.svg, or whatever) operates through the 
renderer interface. For this sort of package, I don't believe the 
renderer interface should be exposed to the user at all. Doing so would 
greatly inhibit the freedom to refactor it down the road. And that 
freedom, I think, is important for long-term maintenance.

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

By "default", I mean "fallback", for cases when there's no, or 
problematic, hardware acceleration available. As to which and how many 
hardware-accelerated backends ship along with that, that's very much 
open to debate. Which versions of OpenGL to support out of the box, 
whether or not a D3D renderer should be included and, if so, which 
version, and so on.

Honestly, I'd prefer not to see this package in Phobos at all. That 
implies a number of constraints, both design time and run time, that 
would not be necessary if it were left as a third-party dub-enabled 
package. Anything in Phobos has to work where D works, be it on a 
headless server or a tweaked-out gaming rig, or on an old system or a 
future one. Maximum portability and maintainability need to take 
priority over performance. If the graphics API can't work in all of 
those possible environments, then it has no business being part of the 
standard library.