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.

Reply via email to