On Tuesday, 7 January 2014 at 17:16:21 UTC, Jacob Carlborg wrote:
> It looks like it will setup the basics, but no more than that. There are some things it doesn't handle and some things it's not handling correctly.

I honestly think it will be easier to maintain and keep up to date with changes in OS-X if done entirely in Objective-C. If you are interested in that then I'd be interested in cooperating on a runtime wrapper that can be used both from C++ and D for OS-X 10.x+ and ios5.1+.

On Tue, 07 Jan 2014 03:52:04 -0800, Iain Buclaw <ibuclaw@gdcproject.org> wrote:

> On 7 Jan 2014 10:20, "Dmitry Olshansky" <dmitry.olsh@gmail.com> wrote:
>>
>> 07-Jan-2014 12:30, Adam Wilson пишет:
>>>
>>> On Tue, 07 Jan 2014 00:05:35 -0800, Ola Fosheim Grøstad
>>> <ola.fosheim.grostad+dlang@gmail.com> wrote:
>>> There is nothing technically wrong with DirectX on Windows
>>> and unlike OpenGL which requires manufacturer provided drivers, it's
>>> guaranteed to be available.
>>
>>
>> Pardon, but this reads like citation of some old crap to me.
>> And how would you use a GPU w/o manufacturer provided drivers?
>> DX also builds on top of vendor specific drivers.
>>
>
> I thought it was the other way round. As in vendors write drivers to
> interface specifically with directX on windows, so Microsoft doesn't have
> to.

I apologize, late-night exhaustion mis-speak. What I meant to say is that unlike DirectX, which due to Aero and WinRT requires that drivers be provided that work with DirectX, Windows does not ship OpenGL in any form, drivers or API's. Therefore the vendor has to ship the OpenGL API's along with the OGL compatible drivers, and not all do since it's not required for Windows certification. Yes, nVidia and ATI do, and that covers the bulk, but it's not universal like DirectX is. On Windows you have absolute certainty on DX always being there, you can't make that assumption with OGL.

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator

More interesting was the link that Herb Sutter provided.

Lightweight Drawing Library
http://isocpp.org/files/papers/n3791.html

Looks like he nailed the problem very well - it will be interesting to see what they come up with.



On Monday, 6 January 2014 at 18:34:53 UTC, Keesjan wrote:
> Another lib to consider is www.cairographics.org
> Herb Sutter wants to base the 2d stuff of c++ on it
> http://lists.cairographics.org/archives/cairo/2013-December/024858.html

On Tue, 07 Jan 2014 05:34:08 -0800, Ola Fosheim Grøstad <ola.fosheim.grostad+dlang@gmail.com> wrote:

> On Tuesday, 7 January 2014 at 13:18:51 UTC, Dmitry Olshansky wrote:
>> The difference might be in that DX is huge framework, and vendors effectively write small "core" for it.
>
> I think this is all just a misunderstanding. Adam probably just meant that DX drivers are being updated automatically by Microsoft while you have to download the GL drivers yourself. But I never meant that the graphics library should expose GL-only functionality...
>
>> With GL the balance could be the other way around, but GL doesn't try to be all of the many facets of the multimedia in the first place.
>> (and now with DirectCompute I'm not even sure what DX wants to be actually)
>
> Yes, and I think this is a very good point for why the reference implementation should not be in DX. You risk ending up with all other platforms having to implement DX components that are not in GL (and there is a lot of them).
>

You seem very concerned that the low-level API will effect the design of the high-level API. If that happens we've failed and need to try again. Plenty of other libraries have done this so I don't see this as anything other than a theoretical risk that can be designed around.

> E.g. in GL you cannot do anything without writing your own shaders and there is no notion of 2D-anything… Many of the GL calls and parameters are actually also legacy calls so the REAL OpenGL ES API that you are likely to use is quite limited and bare bones.
>
> Another reason I've already mentioned is to test feature coverage/performance on multiple platforms which only OpenGL ES enables.
>
> Yet another reason is to allow/encourage as many as possible to dabble with the API early on to increase the usability of it. Which actually might be the most important aspect.

I asked Mike Parker about this at Dconf 2013, with the intent of having a reference implementation. You know what he said? Don't bother. Because in the end it does not matter which implementation you start with, other API's will look different no matter what you do, even for OGL (differing implementations), differing fonts, differing rendering pipelines, etc... His advice was to pick whatever worked best for the implementor and make the other API implementations look as close a possible and have people submit bug reports. Eventually they will match on a per-pixel basis but shooting for that goal out of the gate is a waste of effort.

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator

On Tue, 07 Jan 2014 04:29:58 -0800, Ola Fosheim Grøstad <ola.fosheim.grostad+dlang@gmail.com> wrote:

> On Tuesday, 7 January 2014 at 12:11:49 UTC, qznc wrote:
>> On Monday, 6 January 2014 at 19:13:19 UTC, Ola Fosheim Grøstad Cairo supports defining paths and then drawing/filling them.
>
> Yes, but it is pragmatic in the sense that it apparently makes approximations to arc (circle/ellipsis) and use more expensive cubic primitives for quad beziers. Efficient fonts are often specified as the cheaper quadratic beziers. Cubic beziers look better, but are more expensive. Maybe the backends turn the cubics back into quads, I dunno. I've just looked at the internal path representation.
>
> SVG covers a lot more ground, though. Including image fills, filtereffects and animation.
>
>> I used Cairo (via GtkD) to produce pdf documents. The pdf and png backends are probably pretty unique for a graphics 2D library. Most just target a screen.
>
> I agree that Cairo is cool.
>
> I would personally rather see SVG in a standard library since that is actually the most common vector graphics file format (Inkscape++) and vector engine DOM: IE9+, Firefox, Chrome, Safari etc.
>
> I've just looked at the cinder api, and it looks like an internal library pushed to the public (and yes, it apparently is):
>
> http://libcinder.org/docs/v0.8.5/hierarchy.html
>
> If one want a simple api for messing around with graphics then probably Cairo or Processing would be a better choice, they are at least very popular. Cinder is probably in the difficult intermediate position, not easy enough for most dabblers, and not powerful enough for those who have a strong interest in graphics.
>

Well, that's not what we saw at GoingNative. Mr. Sutter challenged the attendees to code up a game using Cinder in less than 24 hours. Over two dozen people who'd never seen Cinder before responded with games of varying complexity and completeness, but all ran and did game-like things. So I'd have to say that your theoretical appraisal of the API doesn't match the real outcomes we saw.

> If you want something that actually is standard, then the SVG DOM is the only choice, IMHO.
>

SVG has a rep for being verbose and slow to parse (It is basically XML after all). Yes it's supported by all major browsers, I've just never seen anybody actually use it outside some small niches.

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator

On Tuesday, 7 January 2014 at 19:00:46 UTC, Adam Wilson wrote:
> You seem very concerned that the low-level API will effect the design of the high-level API. If that happens we've failed and need to try again.

No, I am afraid that you pick a high-level ENGINE (not HAL API) and dress it up. If you actually use a low level api, it will be shader based and use roughly the same pipeline. DX3D and GL have feature parity if you stay away from the esoteric stuff.

> I asked Mike Parker about this at Dconf 2013, with the intent of having a reference implementation. You know what he said? Don't bother. Because in the end it does not matter which implementation you start with, other API's will look different no matter what you do, even for OGL (differing implementations), differing fonts, differing rendering pipelines, etc...

No. Simple shaders work roughly the same on modern hardware, though you need performance tweaks, avoid accumulated FP errors etc. If you don't depend on system fonts, fonts should not differ.

> His advice was to pick whatever worked best for the implementor and make the other API implementations look as close a possible and have people submit bug reports.

I am arguing in favour of having one reference implementation that is highly portable. There is no need to match up pixels to anything if there is only one solution…

On Tuesday, 7 January 2014 at 19:00:48 UTC, Adam Wilson wrote:
> SVG has a rep for being verbose and slow to parse (It is basically XML after all). Yes it's supported by all major browsers, I've just never seen anybody actually use it outside some small niches.

It is included in your lovely cinder!

SVG has a rich feature set, true enough, so the engines are still not complete, but they are getting there.

On Tue, 07 Jan 2014 11:23:47 -0800, Ola Fosheim Grøstad <ola.fosheim.grostad+dlang@gmail.com> wrote:

> On Tuesday, 7 January 2014 at 19:00:48 UTC, Adam Wilson wrote:
>> SVG has a rep for being verbose and slow to parse (It is basically XML after all). Yes it's supported by all major browsers, I've just never seen anybody actually use it outside some small niches.
>
> It is included in your lovely cinder!
>

True enough, but for the moment we are trying to keep the scope of the project manageable. If someone wants to add it great! But until then we need to focus on what is required.

> SVG has a rich feature set, true enough, so the engines are still not complete, but they are getting there.
>


-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator

On Tue, 07 Jan 2014 11:21:47 -0800, Ola Fosheim Grøstad <ola.fosheim.grostad+dlang@gmail.com> wrote:

> On Tuesday, 7 January 2014 at 19:00:46 UTC, Adam Wilson wrote:
>> You seem very concerned that the low-level API will effect the design of the high-level API. If that happens we've failed and need to try again.
>
> No, I am afraid that you pick a high-level ENGINE (not HAL API) and dress it up. If you actually use a low level api, it will be shader based and use roughly the same pipeline. DX3D and GL have feature parity if you stay away from the esoteric stuff.
>
>> I asked Mike Parker about this at Dconf 2013, with the intent of having a reference implementation. You know what he said? Don't bother. Because in the end it does not matter which implementation you start with, other API's will look different no matter what you do, even for OGL (differing implementations), differing fonts, differing rendering pipelines, etc...
>
> No. Simple shaders work roughly the same on modern hardware, though you need performance tweaks, avoid accumulated FP errors etc. If you don't depend on system fonts, fonts should not differ.
>

That depends on how one defines system fonts I suppose. I was figuring Open/TrueType fonts at least, which are all vector fonts.

>> His advice was to pick whatever worked best for the implementor and make the other API implementations look as close a possible and have people submit bug reports.
>
> I am arguing in favour of having one reference implementation that is highly portable. There is no need to match up pixels to anything if there is only one solution…

Right, but Mike Parker has experience doing this, his opinion counts for quite a bit. His biggest point however is that the high-level API should be completely independent of the low-level API's. The high-level API describes what the user wants and it's up to the graphics API implementor to get it right. To be honest I would rather use a 2D graphics library like cairo that supports OpenGL on Posix systems before we went to the trouble of making OpenGL render 2D shapes in 3D space, I've done that before, it's not easy. One of the more difficult problems is converting 2D pixels into the Cartesian coordinates system while accounting for DPI. It's doable, but it's more a LOT work than working with Direct2D or Cairo or some other suitable API...

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator

On Tuesday, 7 January 2014 at 19:31:38 UTC, Adam Wilson wrote:
> True enough, but for the moment we are trying to keep the scope of the project manageable. If someone wants to add it great! But until then we need to focus on what is required.

Yes, that is true, and then we should define a set of applications which it will be suitable for and what the basic model is: Should it be immediate mode, retained mode or scene graph based?

High level graphic frameworks tend to loose momentum fast, even the good ones. Example: SGI's Open Inventor is actually a neat scene graph framework, and open source, but dead. SGI's GL survived because it was low level and immediate mode.

So, I really think D is better off providing the basics in phobos first, staying true to the virtue of providing independent modules that are focused:

- OS application abstraction: graphics context, input stream, audio playback
- generally useful vector path datatype compatible with phobos-collections and SVG
- vector/matrix library with competitive SSE performance and features such as clamping