On Wednesday, 8 January 2014 at 09:34:20 UTC, Jacob Carlborg
wrote:
I'm saying it would be nice to have access to the platform
handles (and similar) when the high level API isn't enough.
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.
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.
Rendering to a memory buffer to generate png images is a
legitimate use case. If Phobos has a graphics API, I would expect
that to be supported even when no gpu is present.
Do you expect std.net/socket to work without a NIC?
That's different. A gpu is only required for *hardware
accelerated* rendering. And I don't think Phobos should require
it.
I would like to see it as an official library distributed with
D, but not necessarily included in Phobos.
Whether it's distributed with the compiler as an optional package
or simply maintained in the D organization at github and
distributed through dub, either case is better than making it
part of the standard lib, IMO. Then more liberty can be taken
with the requirements.
