Graphics Library for D

[Jacob Carlborg]

On 2014-01-08 09:32, Mike Parker wrote:

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

I'm saying it would be nice to have access to the platform handles (and 
similar) when the high level API isn't enough.

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

I see.

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

I think you're exaggerating a bit. I wouldn't expect a graphics library 
to work if I don't have a screen and/or graphics card. Do you expect 
std.net/socket to work without a NIC?

I would like to see it as an official library distributed with D, but 
not necessarily included in Phobos.

-- 
/Jacob Carlborg