Graphics Library for D

[Adam Wilson]

On Wed, 08 Jan 2014 05:09:52 -0800, Mike Parker <aldacron at gmail.com> wrote:

> On 1/8/2014 9:26 PM, "Ola Fosheim Grøstad"  
> <ola.fosheim.grostad+dlang at gmail.com>" wrote:
>> On Wednesday, 8 January 2014 at 11:34:53 UTC, Mike Parker wrote:
>>> 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.
>>
>> Yes, this is true, but that was not the goal stated at the start of the
>> thread. The linked framework is a wrapper for a hodge podge of graphics
>> technologies that target real time graphics (an internal framework that
>> was developed to do graphics for advertising I think).
>>
>> A generic non-real-time graphics API that is capable of generating PDF,
>> SVG and PNG would be quite useful in web-services for instance. But then
>> it should be based on the graphics model that can be represented
>> efficiently in PDF and SVG.
>
> I could have sworn I read somewhere in this thread that there was talk  
> of including it in Phobos at some point. That's the perspective I've  
> been arguing from. If it's fully intended to be separate from Phobos,  
> then there's no need for any of this and the feature list could  
> certainly be more specific.
>
>>
>> However, if you want interactive graphics, you enter a different domain.
>> An engine that assumes that all geometry change for each frame is quite
>> different from an engine that assumes that most graphics do not change
>> beyond simple affine transforms.
>
> I wouldn't expect any implementation, generic or otherwise, to assume  
> mostly static geometry. You could bet that a simple graphics API in  
> Phobos would be used for games by some and for generating pie charts by  
> others. It's still possible to get a generic rendering system to handle  
> that with decent performance. Yes, it makes for compromises in the  
> backend that a more targeted renderer wouldn't need to make, but that's  
> the price of genericity.
>
>
>>
>> However the argument against shaders/GPU does not hold, I think. Using
>> simple shaders (with your own restricted syntax) does not require a GPU.
>> If you can parse it at compile time you should be able to generate D
>> code for it, and you should be able to generate code for GL/DX at
>> runtime quite easily (probably a few days of work).
>
> This is true. But assuming a) the library is going to be in Phobos and  
> therefore b) there is going to be a software backend, and c) there's a  
> desire for feature parity between the software renderer and any  
> hardware-accelerated backends, then custom shaders increase the  
> complexity of the software implementation quite a bit. There are so many  
> rules needed to guide the implementation in terms of render quality. Ugh!
>
> That's a lot of assumptions, I know. If this is not going to be in  
> Phobos and there's no pressing need for a software renderer then it's  
> moot. In that case, the sky's the limit.

I mentioned the Phobos inclusion at the beginning because I knew that the  
topic would come up but I really had no idea what direction it would take.  
So far, everyone here seems to agree with the idea that only certain  
portions that are not renderer dependent should be include in the standard  
library. In principle, I don't really have a problem with that, however as  
someone pointed out, you don't really expect to be able to use std.socket  
without a NIC, so saying that it shouldn't be in just because not all  
machines have graphics output is tad extreme.

At some point I think that the standard library should include some basic  
graphics rendering. Almost every language in common use today supports  
graphics at some level, or, in the case of C++, are in the process of  
adding it. I lurk on the ISO C++ Forums and the graphics work-group is the  
most attended and discussed future proposal in the entire standard right  
now. People want this.

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator