On Wed, 08 Jan 2014 10:58:37 -0800, Ola Fosheim Grøstad <ola.fosheim.grostad+dlang@gmail.com> wrote:

> 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

That's the one.

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator

On Wednesday, 8 January 2014 at 19:18:03 UTC, Adam Wilson wrote:
> That's the one.

Ah, I like the way they are open to all options.

http://isocpp.org/files/papers/N3825.pdf

I think they are very far away from creating a standard though. With only 3 attendees I think it   probably just is some early ball-tossing intended to attract attention from the computer graphics community.

On Wed, 08 Jan 2014 11:26:58 -0800, Ola Fosheim Grøstad <ola.fosheim.grostad+dlang@gmail.com> wrote:

> On Wednesday, 8 January 2014 at 19:18:03 UTC, Adam Wilson wrote:
>> That's the one.
>
> Ah, I like the way they are open to all options.
>
> http://isocpp.org/files/papers/N3825.pdf
>
> I think they are very far away from creating a standard though. With only 3 attendees I think it   probably just is some early ball-tossing intended to attract attention from the computer graphics community.

Small meeting size probably also has to be with when and where the meeting was. Beyond that, all I can say is that not being part of standard is freeing in certain respects. Namely the laborious process of changing the standard. That said Mr. Sutter is pushing for C++17 inclusion, we shall see.

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator

On Wednesday, 8 January 2014 at 19:51:31 UTC, Adam Wilson wrote:
> Small meeting size probably also has to be with when and where the meeting was. Beyond that, all I can say is that not being part of standard is freeing in certain respects. Namely the

Yes, and also that they are less likely to invent something new, but will be told to just making existing practice formal.

Some discussions are worth looking at though. Like this discussion of pixel coordinates:

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

Personally, I think that allowing multiple graphics contexts to the same surface is the better approach, so that you can scale it to either be in the range ([0,1],[0,1]), ([-1,1],[-1,1]), ([0,width],[0,height]), etc

e.g.:

g = surface.getContext().resetScaleNormalizedCenter(); // normalized to [-1,1]
gwh = surface.getContext().resetScaleWidthHeight(); // vertices in pixel coordinates
gretina = gwh.clone().scale(2,2); // vertices in points coordinates

g.plot(-1,-1); //upper left corner
gwh.plot(0,0); //upper left corner
etc.

And well the c++ guys are right when pointing to html5 canvas. It is close enough to postscript and well worth having a look at for those who don't know it. It is semi-immediate mode, in the sense that it allows implementations to retain a log of draw commands.

http://www.w3.org/TR/2dcontext/

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

The development of AGG has pretty much stopped after the original author released 2.4.  The 2.5 is no more than just a license change (I remember I have compared the files).

The fork on SourceForge, although considered maintained, it contains only a few small changes. Right now the revision number of that repo is only about 90, and there isn't much happening in the repo over the years. I think if we pick up the 2.4 version, convert it to idiomatic D, it would be very good showcase of D's template capability.

The thing I like about AGG is that it is very portable (I have ported it to embedded micro controllers in a matter of minutes). That is because all it requires is just a pixel buffer and a C++ compiler.  It is also very fast for a high quality software renderer, so if extreme performance is not high on your priority list, AGG is a very good fit for you needs. And also because it's a pure software renderer that works on pixel buffers, it's a good candidate to be included in Phobos.

On Wed, 08 Jan 2014 15:11:33 -0800, finalpatch <fengli@gmail.com> wrote:

> On Wednesday, 8 January 2014 at 18:49:58 UTC, Adam Wilson wrote:
>>>
>>> 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.
>
> The development of AGG has pretty much stopped after the original author released 2.4.  The 2.5 is no more than just a license change (I remember I have compared the files).
>
> The fork on SourceForge, although considered maintained, it contains only a few small changes. Right now the revision number of that repo is only about 90, and there isn't much happening in the repo over the years. I think if we pick up the 2.4 version, convert it to idiomatic D, it would be very good showcase of D's template capability.
>
> The thing I like about AGG is that it is very portable (I have ported it to embedded micro controllers in a matter of minutes). That is because all it requires is just a pixel buffer and a C++ compiler.  It is also very fast for a high quality software renderer, so if extreme performance is not high on your priority list, AGG is a very good fit for you needs. And also because it's a pure software renderer that works on pixel buffers, it's a good candidate to be included in Phobos.

Even with a full port of 2.4 to D it would still fall under the BSD 3-Clause license which is not Boost compliant IIRC. So it will never end up in Phobos. If I am missing something let me know, because a Phobos Software Renderer is a good idea.

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator

On Wednesday, 8 January 2014 at 23:11:34 UTC, finalpatch wrote:
> The fork on SourceForge, although considered maintained, it contains only a few small changes. Right now the revision number of that repo is only about 90, and there isn't much happening in the repo over the years. I think if we pick up the

Sadly, the author apparently died in november:

http://www.microsofttranslator.com/bv.aspx?from=ru&to=en&a=http://rsdn.ru/forum/life/5377743.flat

On Wednesday, 8 January 2014 at 23:29:59 UTC, Adam Wilson wrote:
> Even with a full port of 2.4 to D it would still fall under the BSD 3-Clause license which is not Boost compliant IIRC. So it will never end up in Phobos. If I am missing something let me know, because a Phobos Software Renderer is a good idea.

Hi Adam,

We don't necessarily have to port AGG to D. Instead, I suggest we produce something that resembles its design (a set of very flexible components that can be put together through template instantiation at compile time), but in idiomatic D.  With the power of D, the group wisdom of the community, and the lessons learned from AGG and other prior projects, it's very possible we can produce something even more impressive than AGG. Since it's a pure software renderer, the scope of the project will be a lot more manageable than GPU based solutions.

On Wed, 08 Jan 2014 15:56:18 -0800, finalpatch <fengli@gmail.com> wrote:

> On Wednesday, 8 January 2014 at 23:29:59 UTC, Adam Wilson wrote:
>> Even with a full port of 2.4 to D it would still fall under the BSD 3-Clause license which is not Boost compliant IIRC. So it will never end up in Phobos. If I am missing something let me know, because a Phobos Software Renderer is a good idea.
>
> Hi Adam,
>
> We don't necessarily have to port AGG to D. Instead, I suggest we produce something that resembles its design (a set of very flexible components that can be put together through template instantiation at compile time), but in idiomatic D.  With the power of D, the group wisdom of the community, and the lessons learned from AGG and other prior projects, it's very possible we can produce something even more impressive than AGG. Since it's a pure software renderer, the scope of the project will be a lot more manageable than GPU based solutions.

Well, actually software renderers are terribly complicated beasts and so probably wouldn't reduce the actual scope. And they require a lot of mathematical knowledge that can be hard to come by, I certainly don't have it. So if someone is willing to start writing one in D we'd be happy to include support for it in Aurora. But I think we should continue with the GPU based solutions because they are easier to work with and the knowledge-base is more extensive.

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator