http://libagar.org/index.html.en

On Monday, 6 January 2014 at 07:30:25 UTC, Joakim wrote:
> On Monday, 6 January 2014 at 04:17:21 UTC, Walter Bright wrote:
>> On 1/5/2014 8:10 PM, Adam Wilson wrote:
>>> Recently, I've been working to evaluate the feasibility and reasonability of
>>> building out a binding to Cinder in D.
>>
>> For reference, here's what Cinder is:
>>
>> http://libcinder.org/
>>
>> It's been well received by the C++ community.
>
> I took a look at the website.  Other than being popular what is it about Cinder that triggered this graphics push: do they make any good technical decisions?  I can't tell just from looking at their website.

Agreed, the web site does not give you any clear impression of what it does!

"Adam Wilson" <flyboynw@gmail.com> wrote in message news:op.w9d7xdpk707hn8@invictus.skynet.com...
> 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.

I really dont know why this algorithm is not better known but it's very fast, good quality and very simple to implement. I knocked up my own version in a couple of days (aprox 500 LOC for the rasterizer, and a bunch of asm for the line blitters). It has speed/quality comparisions with GDI+ and AGG on the website. There's C++ source code IIR, dont know about the licence.

http://mlab.uiah.fi/~kkallio/antialiasing/

Hi

I'm a new contributor to this site - I'm trying D out, and liking it a lot. Though I'm new to D, my background is in computer graphics, so I'm excited to see graphics capabilities being discussed, and I thought I'd add my two-penneth.

Firstly, there seems to be disagreement on exactly what is to be developed. I've seen 3 types of things discussed.

1. GUI Library. It seems to me that a really well designed GUI system would be - by far - the most valuable thing for increasing the widespread use of D. I would use it in a heartbeat if such a thing existed.

2. 2D/3D Graphics interface to underlying hardware. This can be useful - though it's not clear to me that the 2D part would be terribly useful on its own, without 3D OpenGL support, or possibly acting as primitives for a GUI library. I suppose 2D games could use it.

3. High quality 2D, SVG-style renderer, capable of rendering to arbitrary bitmaps. Not sure what the point of this is, or who would use it. At any rate, it seems sufficiently specialised that it doesn't belong in a core library.

If it were up to me (I know, it isn't) - I would create a graphics system for D based on a modern web-browser's Javascript DOM. I daresay not everything would map well to D, but I would start with that, and adapt it where necessary. I would include WebGL 2.0 support, mouse handling callbacks etc.

But that's just me :-)

Best Regards

Matt Taylor

On Mon, 13 Jan 2014 15:46:42 -0800, Matt Taylor <taylorius@gmail.com> wrote:

> Hi
>
> I'm a new contributor to this site - I'm trying D out, and liking it a lot. Though I'm new to D, my background is in computer graphics, so I'm excited to see graphics capabilities being discussed, and I thought I'd add my two-penneth.
>

Welcome! We could use all the help we can get! I'll be announcing firmer plans this weekend after I've had a chance to write them out. Stay tuned.

> Firstly, there seems to be disagreement on exactly what is to be developed. I've seen 3 types of things discussed.
>
> 1. GUI Library. It seems to me that a really well designed GUI system would be - by far - the most valuable thing for increasing the widespread use of D. I would use it in a heartbeat if such a thing existed.
>

Aurora is not a GUI library.

> 2. 2D/3D Graphics interface to underlying hardware. This can be useful - though it's not clear to me that the 2D part would be terribly useful on its own, without 3D OpenGL support, or possibly acting as primitives for a GUI library. I suppose 2D games could use it.
>

This is what Aurora is intended to be. The 2D part could be used as the building blocks for a GUI or games or whatever else you can come up with. Aurora is intended to be a general-purpose graphics library for D. It should be usable on any device/platform that D supports or will support.

> 3. High quality 2D, SVG-style renderer, capable of rendering to arbitrary bitmaps. Not sure what the point of this is, or who would use it. At any rate, it seems sufficiently specialised that it doesn't belong in a core library.
>

I tend to agree that SVG is a bit specialized for our purposes with Aurora. If someone wants to implement an SVG renderer on top of Aurora though, that would be valid and useful but not within the scope of Aurora itself.

> If it were up to me (I know, it isn't) - I would create a graphics system for D based on a modern web-browser's Javascript DOM. I daresay not everything would map well to D, but I would start with that, and adapt it where necessary. I would include WebGL 2.0 support, mouse handling callbacks etc.
>

Do you mean HTML DOM? This would be similar to XAML and both are UX languages which are unrelated to the purpose and goal of Aurora. And don't think this would translate to well into D code. One of the goals is to use idiomatic D as much as possible.

> But that's just me :-)
>
> Best Regards
>
> Matt Taylor
>

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator

On Tuesday, 14 January 2014 at 02:32:01 UTC, Adam Wilson wrote:
> I tend to agree that SVG is a bit specialized for our purposes

This is a misconception. SVG is a generic scene-graph-like DOM. Much in the same vain as OpenInventor and Flash (or Coin3D, which is a free implementation of OpenInventor). SVG is a hierarchy of transformations and shapes. It is very close to being a retained mode version of Display Postscript, which IS the graphics library of NeXT and very close to the generic graphics libraries of OS-X (Quartz) which is heavily based on NeXT. (And probably Direct2D too).

On Tuesday, 14 January 2014 at 02:32:01 UTC, Adam Wilson wrote:
> On Mon, 13 Jan 2014 15:46:42 -0800, Matt Taylor <taylorius@gmail.com> wrote:

>> 2. 2D/3D Graphics interface to underlying hardware. This can be useful - though it's not clear to me that the 2D part would be terribly useful on its own, without 3D OpenGL support, or possibly acting as primitives for a GUI library. I suppose 2D games could use it.
>>
>
> This is what Aurora is intended to be. The 2D part could be used as the building blocks for a GUI or games or whatever else you can come up with. Aurora is intended to be a general-purpose graphics library for D. It should be usable on any device/platform that D supports or will support.
>

Is Aurora exclusively 2D? Or will 3D get a look in?

>
>> If it were up to me (I know, it isn't) - I would create a graphics system for D based on a modern web-browser's Javascript DOM. I daresay not everything would map well to D, but I would start with that, and adapt it where necessary. I would include WebGL 2.0 support, mouse handling callbacks etc.
>>
>
> Do you mean HTML DOM? This would be similar to XAML and both are UX languages which are unrelated to the purpose and goal of Aurora. And don't think this would translate to well into D code. One of the goals is to use idiomatic D as much as possible.

Definitely not.  The web browser's DOM is a completely separate entity to HTML (even though HTML is commonly used to populate it on a webpage). A webpage can be constructed entirely programatically in javascript. Personally I wouldn't allow HTML,XAML or any other ML within a mile of my code. :-) No, I'm definitely talking about pure D. What we take from the DOM is it's structure and capabilities (i.e the Javascript DOM API), and then reinterpret that API into idiomatic D.



The thing with a 2D graphics API, is deciding what level you want it to work at. For example SDL is a 2D graphics API of sorts - it gives you a pixel array, and you can set each pixel to whatever colour you like.

Meanwhile, at the other end of the scale, you have a system with the capabilities of the Javascript DOM (see above), or the Flash player. This system can composite multiple 2D layers, and keep track of the contents of those layers.

Having said all that, I've a feeling that my thoughts are heading in a different direction to what you had planned :-) so forgive me if I'm merely distracting you from the task at hand.


Cheers

Matt

On Tuesday, 14 January 2014 at 10:44:57 UTC, Matt Taylor wrote:
> Meanwhile, at the other end of the scale, you have a system with the capabilities of the Javascript DOM (see above), or the Flash player. This system can composite multiple 2D layers, and keep track of the contents of those layers.

Yes, this is the scene graph approach. This is basically SVG, a hierarchy of transforms, shapes and interactive nodes. A retained mode version of Display Postscript. Although OpenInventor has a more powerful model, perhaps (Coin3D is freely available as a starting point).

The Flash model is formalized as as a DOM in StageXL: http://www.stagexl.org/

Another scene graph that was used in X11 servers is PHIGS.

On Tuesday, 14 January 2014 at 11:10:36 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 14 January 2014 at 10:44:57 UTC, Matt Taylor wrote:
>> Meanwhile, at the other end of the scale, you have a system with the capabilities of the Javascript DOM (see above), or the Flash player. This system can composite multiple 2D layers, and keep track of the contents of those layers.
>
> Yes, this is the scene graph approach. This is basically SVG, a hierarchy of transforms, shapes and interactive nodes. A retained mode version of Display Postscript. Although OpenInventor has a more powerful model, perhaps (Coin3D is freely available as a starting point).
>
> The Flash model is formalized as as a DOM in StageXL: http://www.stagexl.org/
>
> Another scene graph that was used in X11 servers is PHIGS.

No please not PHIGS....I had to use PHIGS way back when, before we switched to Inventor. Inventor is a much nicer API.

But whatever you guys come up with will obviously be well thought out. Cannot wait to see it progress further.

Cheers,
Ed

On Tuesday, 14 January 2014 at 11:10:36 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 14 January 2014 at 10:44:57 UTC, Matt Taylor wrote:
>> Meanwhile, at the other end of the scale, you have a system with the capabilities of the Javascript DOM (see above), or the Flash player. This system can composite multiple 2D layers, and keep track of the contents of those layers.
>
> Yes, this is the scene graph approach. This is basically SVG, a hierarchy of transforms, shapes and interactive nodes. A retained mode version of Display Postscript. Although OpenInventor has a more powerful model, perhaps (Coin3D is freely available as a starting point).

Indeed, though OpenInventor is a 3D scene graph of course. I don't think it's advisable to try and shoehorn 2D and 3D into one system. For my money, web browsers have it about right - a standardised DOM for 2D (albeit with the odd 3D css trick available these days) and WebGL for the "real" 3D. Not only that, but loads of people are already familiar with how they work.

Cheers

Matt