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
