Graphics Library for D

Mike Parker aldacron at gmail.com
Wed Jan 8 03:34:52 PST 2014


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.


More information about the Digitalmars-d mailing list