On Tuesday, 7 January 2014 at 08:50:28 UTC, Ola Fosheim Grøstad wrote:
> If you want cross platform performance your only choice is to pick a DX compatible subset of OpenGL ES 2/3 and use that as

Just in case this isn't obvious: you need a reference implementation during API design in order to track performance and feature regressions on a wide range of systems and GPU types (e.g. mobile tile based GPUs work differently from regular desktop GPUs). The goal of the reference is not to obtain optimal performance, but to ensure that acceptable performance and resource usage is attainable across the set of target systems without limiting the feature set.

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.

On Monday, 6 January 2014 at 19:13:19 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 6 January 2014 at 18:34:53 UTC, Keesjan wrote:
>> Another lib to consider is www.cairographics.org
>
> I think Cairo only support straight lines and cubic bezier curves in what appears to be a somewhat inefficient format, but the backend support is quite extensive.

Cairo supports defining paths and then drawing/filling them. This is all you need for basic 2D images, no? Well, then you can embed other pictures/framebuffers and clip/transform them. There is no photoshop-filter like effects, though. What do you expect?

Cairo also has some naive text support, but you probably want to use Pango for text, which is closely integrated with Cairo.

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.

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.

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

07-Jan-2014 15:52, Iain Buclaw пишет:
> On 7 Jan 2014 10:20, "Dmitry Olshansky" <dmitry.olsh@gmail.com
> <mailto: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
> <mailto:ola.fosheim.grostad%2Bdlang@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.

As with all drivers they do follow interfaces for directX to build upon.
And there is the same thing with OpenGL and the way it integrates with the windows.
The difference might be in that DX is huge framework, and vendors effectively write small "core" for it.
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)

-- 
Dmitry Olshansky

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

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.

On 2014-01-07 09:18, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:

> Yes, but you can call D as a library from an Objective-C runtime.
>
> 1. Objective-C main() calls D main().
> 2. D main creates OSApplication facade and calls run(someDfunc) on it.
> 3. Objective-C event loop call back to someDfunc

Yes, sure. In theory it sounds easy. Although I suspect access to more of the Objective-C API's are necessary. That would either require more Objective-C code or using D, which comes back to the original problem.

-- 
/Jacob Carlborg

On Tuesday, 7 January 2014 at 14:31:07 UTC, Jacob Carlborg wrote:
> On 2014-01-07 09:18, "Ola Fosheim Grøstad" Yes, sure. In theory it sounds easy. Although I suspect access to more of the Objective-C API's are necessary. That would either require more Objective-C code or using D, which comes back to the original problem.

Yep, you're right. You need to set up the OpenGL context  from Objective-C, and the callbacks and... and... ;-)

So getting the OSApplication right for all platforms (uniform facade) is an abstraction challenge, but the OpenGL calls are pure C, so the Objective-C stuff is mostly about initialization and setting up hooks for exception handling (like being put to sleep, being asked to free memory/resources,...)

You probably don't need more than 500-1000 lines of Objective-C.

A while ago, someone contributed D code to my simpledisplay.d that make an obj-c window. Sadly though, I haven't maintained it at all* and I'm sure it no longer compiles. But, it might be fixable, at least to get the basics up again.

* I don't have a mac. A few months ago, I tried to.... acquire a copy OSX to run in a VM for these purposes, but I couldn't actually get it to boot and gave up on it.

On 2014-01-07 17:10, Adam D. Ruppe wrote:
> A while ago, someone contributed D code to my simpledisplay.d that make
> an obj-c window. Sadly though, I haven't maintained it at all* and I'm
> sure it no longer compiles. But, it might be fixable, at least to get
> the basics up again.

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.

It uses the ugly, verbose and cumbersome Objective-C runtime functions, which are C functions. Which I really like to _not_ have to write. The whole reason for my answer.

It also uses some CoreFoundation functions, which also are C functions, to avoid using some of Objective-C API's.

-- 
/Jacob Carlborg