On Wednesday, 8 January 2014 at 02:38:11 UTC, Mike Parker wrote:
> It is very much possible. There are a number of high-level graphics APIs out there designed in just such a way, many of which predate shader APIs. Java2D is a prominent one.

Java2D is a Display Postscript wannabe.
Direct2D is a Display Postscript wannabe.
Quartz is a Display Postscript wannabe.
Cairo is a Display Postscript wannabe.

If you want a Display Postscript API. Then say so.

However, these implementations are probably incompatible when it comes to the lower level compositor, what level of access you have to the compositor and so on. So NO! You cannot just make a high level design without favouring one platform over another. You have to either ANALYZE all platforms and find a subset that performs well across the board OR pick a solution that is cross platform, like Cairo.

You do not want inconsistent performance across platforms for an interactive API, that makes porting software time consuming and expensive.

SVG is the better choice though because it is a retained mode API that actually is a standard and it hides the compositor.

> For the sort of package we're discussing here, you should never define the high-level API in terms of low-level API features. Shaders shouldn't even enter into the equation. That's the sort of backend implementation detail that users of the API shouldn't have to worry about.

If you want access to the compositor you certainly will have to!

> model your API more closely to the hardware. But for a general-purpose graphics API that needs to be available on as many devices as possible, that's not going to work.

Blindly inventing your own Display Postscript and Compositor is most certainly going to make it non-interactive/not-implemented on a wide array of devices.

> It's quite possible to put together a reasonably performant, easy-to-use, general purpose graphics API that can take advantage of the best renderer on a given platform without letting the low-level details leak into the high-level design.

No, it is most certainly not possible to come up with a PORTABLE design for INTERACTIVE graphics without taking the lower level layer into consideration.

That will only work if you implement your own scanline-renderer. Which is slow.

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

> It's only necessary to have an abstract renderer interface with concrete
> backend implementations at the lowest level. Then user-facing API
> (std.gfx.geometry, std.gfx.svg, or whatever) operates through the
> renderer interface. For this sort of package, I don't believe the
> renderer interface should be exposed to the user at all. Doing so would
> greatly inhibit the freedom to refactor it down the road. And that
> freedom, I think, is important for long-term maintenance.

I'm saying it would be nice to have access to the platform handles (and similar) when the high level API isn't enough.

> By "default", I mean "fallback", for cases when there's no, or
> problematic, hardware acceleration available. As to which and how many
> hardware-accelerated backends ship along with that, that's very much
> open to debate. Which versions of OpenGL to support out of the box,
> whether or not a D3D renderer should be included and, if so, which
> version, and so on.

I see.

> Honestly, I'd prefer not to see this package in Phobos at all. That
> implies a number of constraints, both design time and run time, that
> would not be necessary if it were left as a third-party dub-enabled
> package. Anything in Phobos has to work where D works, be it on a
> headless server or a tweaked-out gaming rig, or on an old system or a
> future one. Maximum portability and maintainability need to take
> priority over performance. If the graphics API can't work in all of
> those possible environments, then it has no business being part of the
> standard library.

I think you're exaggerating a bit. I wouldn't expect a graphics library to work if I don't have a screen and/or graphics card. Do you expect std.net/socket to work without a NIC?

I would like to see it as an official library distributed with D, but not necessarily included in Phobos.

-- 
/Jacob Carlborg

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.

----------------
On Monday, 6 January 2014 at 04:11:07 UTC, Adam Wilson wrote:
> Hello Fellow D Heads,
>
> Recently, I've been working to evaluate the feasibility and reasonability of building out a binding to Cinder in D. And while it is certainly feasible to wrap Cinder, that a binding would be necessarily complex and feel very unnatural in D.
>
> So after talking it over with Walter and Andrei, we feel that, while we like how Cinder is designed and would very much like to have something like it available in D, wrapping Cinder is not the best approach in the long-term.
>
> With that in mind, we would like to start a discussion with interested parties about building a graphics library in the same concept as Cinder, but using an idiomatic D implementation from the ground up. Walter has suggested that we call it Aurora, and given the visual connotations associated with that name, I think it is most appropriate for this project.
>
> I know that the community has worked through a few of the problems involved. For example, I can't remember who wrote it, but I've seen a module floating around that can create a window in a cross-platform manner, and I know Mike Parker has been heavily involved in graphics for D. And no discussion of graphics would be complete without Manu, whose input Walter, Andrei, and I would greatly appreciate.
>
> I want to point out that while Cinder will be the design template, the goal here is to use D to it's maximum potential. I fully expect that what we end up with will be quite different than Cinder.
>
> Due to the scope of the project I think it would be best to execute the project in stages. This will allow us to deliver useful chunks of working code to the community. Although I haven't yet heard anything on the subject, I would assume that once Aurora reaches an acceptable quality bar it would be a candidate for inclusion in Phobos, as such I would like to approach the design as if that were the end goal.
>
> The logical phases as I can see them are as follows, but please suggest changes:
>
> - Windowing and System Interaction (Including Keyboard/Mouse/Touch Input)
> - Basic Drawing (2D Shapes, Lines, Gradients, etc)
> - Image Rendering (Image Loading, Rendering, Modification, Saving, etc.)
> - 3D Drawing (By far the most complex stage, so we'll leave it for last)
>
> Here are a couple of things that Aurora is not intended to be:
> - Aurora is not a high-performance game engine. The focus is on making a general purpose API  that is accessible to non-graphics programmers. That said, we don't want to purposely ruin performance and any work and guidance on that aspect will be warmly welcomed.
> - Aurora is not a GUI library. Aurora is intended as a creative graphics programming library in the same concept as Cinder. This means that it will be much closer to game's graphics engine, in terms of design and capability, than a UI library; therefore we should approach the design from that standpoint.
>
> My personal experience in graphics programming is almost completely with DirectX and Windows so I would be happy to work on support for that platform. However, we need to support many other platforms, and I know that there are others in the community have the skills needed, your help would be invaluable.
>
> If you are interested in helping with a Cinder like library for D and/or have code you'd like to contribute, let's start talking and see what happens.
>
> While I do have some ideas about how to design the library, I would rather open the floor to the community first to see what our combined intellect has to offer as I don't want to unduly influence the ideas generated here. The idea is to build the best technical graphics library that we can, not measure egos.
>
> So with the above framework in mind, let's talk!

> No, it is most certainly not possible to come up with a PORTABLE design for INTERACTIVE graphics without taking the lower level layer into consideration.
>
> That will only work if you implement your own scanline-renderer. Which is slow.
-------------------
While I don't know much about the details of rendering graphics. I have enough experience with developing libraries, to know that you can abstract away pretty much anything.

Why do you think interactive graphics would be any different?

On Wednesday, 8 January 2014 at 11:10:10 UTC, Boyd wrote:
> graphics. I have enough experience with developing libraries, to know that you can abstract away pretty much anything.

This sentence makes no sense to me.

Most 2D libraries implement Adobe's 2D model, which is embedded in Postscript, PDF and SVG (all defined by Adobe). This is not a God given model. Neither is having cubic beziers as a primitive. It is all because of Adobe being the industry leader and beziers being prevalent.

> Why do you think interactive graphics would be any different?

1. I don't agree that you can "abstract" anything without bias. There is no God given graphics model.

2. Because they are real time. There is a reason for why Flash is based on quadratic beziers and not cubic beziers, or even more complex (but better) spline bases.

On Wednesday, 8 January 2014 at 09:34:20 UTC, Jacob Carlborg wrote:

>
> I'm saying it would be nice to have access to the platform handles (and similar) when the high level API isn't enough.
>

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.

>> Honestly, I'd prefer not to see this package in Phobos at all. That
>> implies a number of constraints, both design time and run time, that
>> would not be necessary if it were left as a third-party dub-enabled
>> package. Anything in Phobos has to work where D works, be it on a
>> headless server or a tweaked-out gaming rig, or on an old system or a
>> future one. Maximum portability and maintainability need to take
>> priority over performance. If the graphics API can't work in all of
>> those possible environments, then it has no business being part of the
>> standard library.
>
> I think you're exaggerating a bit. I wouldn't expect a graphics library to work if I don't have a screen and/or graphics card.

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.


> Do you expect std.net/socket to work without a NIC?
>

That's different. A gpu is only required for *hardware accelerated* rendering. And I don't think Phobos should require it.


> I would like to see it as an official library distributed with D, but not necessarily included in Phobos.

Whether it's distributed with the compiler as an optional package or simply maintained in the D organization at github and distributed through dub, either case is better than making it part of the standard lib, IMO. Then more liberty can be taken with the requirements.

On Wednesday, 8 January 2014 at 10:57:46 UTC, Boyd wrote:
> 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.

It would be great to have a AGG-like software renderer. It would also be a good showcase for D template capabilities.
Also software rendering is expected to run identical in all cases, and with no drivers dependency, that makes it a huge plus for some use case like audio plugins.

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.

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.

If you decide that most surface do not change (beyond affine transforms) and want a portable graphics solution, you either write your own compositor (in D) on top of the common GPU model, or you use an engine which provides a hidden compositor (like SVG, and even Flash).

With a compositor you can let your "non real time" graphics API to write to surfaces that are used by that compositor. Thus, the real time requirements for graphic primitives are much lower. But it is more work for the programmer than using a high level retained mode engine such as SVG.

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

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.

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

Sure, right.

> That's different. A gpu is only required for *hardware accelerated*
> rendering. And I don't think Phobos should require it.

Right.

> Whether it's distributed with the compiler as an optional package or
> simply maintained in the D organization at github and distributed
> through dub, either case is better than making it part of the standard
> lib, IMO. Then more liberty can be taken with the requirements.

It makes a big difference. It's all about what you can expect to be available if a D compiler is present.

-- 
/Jacob Carlborg

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.