On 1/8/2014 9:59 PM, Jacob Carlborg wrote:
> On 2014-01-08 12:34, Mike Parker wrote:
>
>> 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.
>
> The question is how much you're gaining by hiding it.
>

The first thing that comes to mind is protecting render state. If you expose the low-level details, you give the user the ability to change the render state. This is a big deal in OpenGL, given its state-based nature (though less so with 4.x as I understand it). If you expose that, then that means the backend has to constantly set and reset state in case the user has done anything independently, impacting performance for the majority of people who don't need that low-level access. As long as its hidden, then the implementation can manage state changes more efficiently. Unless, of course, you don't expose the lowest level (OpenGL) but instead wrap state management in an interface that you expose. Now, you've added complexity to your interface just for a small subset of users. This becomes a big deal when implementing and maintaining multiple backends.

I really feel that a graphics API should choose between simplicity and power (high performance, custom special effects). This can help streamline the API and make design decisions in the interest of the target group. Trying to support both is only going to result in an API that's possibly harder to use and certainly more difficult to maintain.

On 2014-01-08 14:09, Mike Parker wrote:

> 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.

In the first post it says something about inclusion in Phobos. I interpreted the post like that as well.

-- 
/Jacob Carlborg

On Wednesday, 8 January 2014 at 13:09:39 UTC, Mike Parker wrote:
> 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.

Well, the goals are very unclear to me, but I guess this discussion and the friction between differing assumptions will sort out what belongs in a standard library :-)

From my perspective Phobos should only provide building blocks that are generally useful for many different applications. I don't think a real time graphics engine belongs in the standard distribution. Real time engines tend to be short lived.

I think the basic setup for each platform belongs there. The same tedious stuff that most apps on a platform have to deal with in order to get started with real time stuff. Once you have a GL/DX context on your hands you can get application stuff going in D with C bindings and a sample application (graphical hello world) would probably be better than a complete framework.

> 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.

2D games, web browsers etc use geometry that is mostly static between frames (although it can be hidden). So you can cache and have a dirty-flag on each surface (if the path-data change you set the dirty flag and the engine recreates the cached surface). 3D is different because of the perspective effect which force you to a complete redraw every frame.

> 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 think you can have the building blocks in Phobos:

1. A path datastructure that can be used for vector path manipulation (fully SVG/postscript/PDF compatible). Useful both for rendering and if you want to do editing/transforms of file formats etc.

2. A simple D-compatible shader language with parser and ability to generate common shader languages (also the the non GL/DX ones used by various multimedia applications for movie effects). The shader language could be this simple:

"r=src1*0.4; g=src1*0.2; b=src1*0.8; a=1.0;"

It could be so simple that you could embed it in your D rendering loop verbatim, as D code.

3. A software path based renderer in D that generate image masks that use (1++) as input.

4. A software compositor that can generate PNG and PDF based on (1) and (2), and SVG if you only use builtin shaders (the fill types supported by SVG).

5. A portable 2D compositor framework, that basically takes byte-masks from any source (could be a vector renderer) and images and compose them using very simple shaders.

Creating a compositor that performs well with many small objects is work though, because you need to maintain a texture atlas and heuristics for how to group etc…

You could probably configure a D-based compositor using templates, so I guess the hard part is figuring out what you need on the platform specific level to support a compositor written fully in D.

If you go the compositor route nothing prevents you from giving access to the GL/DX context, before/after the compositor is done rendering for those with advanced needs.

It is possible to implement 1,2 and 3 before designing 4 and 5. And at the end of the day 4 and 5 probably does not belong in the distribution, while 1,2,3 might.

On Wednesday, 8 January 2014 at 13:22:21 UTC, Mike Parker wrote:
> as I understand it). If you expose that, then that means the backend has to constantly set and reset state in case the user has done anything independently,

If you allow callbacks during the rendering process you should discourage it and put the burden of restoring state on the user, but you only need to do this when rendering transparent faces and Vertex Array Objects helps some. It is safe to allow it before/after rendering solid faces and when done with transparent though.

On Wed, 08 Jan 2014 02:57:45 -0800, Boyd <gaboonviper@gmx.net> wrote:

> I could definitely use something like this. I'm currently working on a GUI library, and I still could use a decent graphics back-end. I suspect Aurora could function in this capacity.
>
> I would love to contribute, though my experience with graphics is mostly limited to Win32 GDI. However, I could probably help with testing it in the early stages.
>
> Also, I'm wondering if you are planning to include(or at least support a possible implementation) perfect anti-aliasing and stuff like that. I know AntiGrain has been mentioned here, I've used it in the distant past for text rendering, and it was pretty cool to have that kind of quality. For a lot of applications, the performance won't be effected much by this, and in some applications quality is very important.

I've been looking at AGG, and to me the biggest problem is the license. It would it difficult to use in commercial scenarios that D itself is perfectly safe in. As useful as the GPL is, I don't think it belongs in a library project.

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator

On 1/8/14, 11:28 AM, Adam Wilson wrote:
> I've been looking at AGG, and to me the biggest problem is the license.
> It would it difficult to use in commercial scenarios that D itself is
> perfectly safe in. As useful as the GPL is, I don't think it belongs in
> a library project.

I think if you're willing to use version 2.4 then you get a much more permissive license, no? That's how I read http://www.antigrain.com/license/index.html anyway...

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

> On 1/8/2014 9:26 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@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

On Wed, 08 Jan 2014 10:39:08 -0800, David Gileadi <gileadis@nspmgmail.com> wrote:

> On 1/8/14, 11:28 AM, Adam Wilson wrote:
>> I've been looking at AGG, and to me the biggest problem is the license.
>> It would it difficult to use in commercial scenarios that D itself is
>> perfectly safe in. As useful as the GPL is, I don't think it belongs in
>> a library project.
>
> I think if you're willing to use version 2.4 then you get a much more permissive license, no? That's how I read http://www.antigrain.com/license/index.html anyway...

Right, it will just force us to become responsible for maintaining our own fork of AGG. I'm not sure we should get into that business.

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator

On 1/8/14, 11:48 AM, Adam Wilson wrote:
> On Wed, 08 Jan 2014 10:39:08 -0800, David Gileadi
> <gileadis@nspmgmail.com> wrote:
>
>> On 1/8/14, 11:28 AM, Adam Wilson wrote:
>>> I've been looking at AGG, and to me the biggest problem is the license.
>>> It would it difficult to use in commercial scenarios that D itself is
>>> perfectly safe in. As useful as the GPL is, I don't think it belongs in
>>> a library project.
>>
>> I think if you're willing to use version 2.4 then you get a much more
>> permissive license, no? That's how I read
>> http://www.antigrain.com/license/index.html anyway...
>
> Right, it will just force us to become responsible for maintaining our
> own fork of AGG. I'm not sure we should get into that business.

Or we could use http://sourceforge.net/projects/agg/, which wikipedia says is a maintained fork of 2.4 (and how could wikipedia be wrong?).

On Wednesday, 8 January 2014 at 18:44:33 UTC, Adam Wilson wrote:
> 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.

This group?

https://groups.google.com/a/isocpp.org/forum/?fromgroups#!forum/graphics