On Sunday, 19 January 2014 at 17:44:57 UTC, ponce wrote:
> On Sunday, 19 January 2014 at 03:38:30 UTC, Adam Wilson wrote:
>>
>> Since Aurora has a pluggable backend for rendering I feel that it will be prudent to use the low-level API's that are best suited to each platform. This will Aurora to support each platform as best as possible. As I currently can tell the following list represents
>>
>> System		 2D API   / 3D API
>> Linux		  X11      / OpenGL 4.3
>> Android		Canvas	 / OpenGL ES 3.0
>> OSX		    Quartz2D / OpenGL 4.3
>> iOS		    Quartz2D / OpenGL ES 3.0
>> Windows		Direct2D / Direct3D 11
>> Windows	RT     Direct2D / Direct3D 11
>
> I'm not really sold on the 2D API not written on top of the 3D API.
> Either way, I don't think X11 should be used instead of OpenGL.
> I think you should target D3D9 instead of D3D11 on Windows.

My vote would be for selectable back ends, with OpenGL availability across the board. This opens up the possibility to do some cross platform 3d graphics with some d binding of OpenGL, using aurora's rendering context. I know it's not what aurora is for, but it would be useful, and wouldn't cost much to allow.

Cheers

Matt

On 01/18/2014 10:38 PM, Adam Wilson wrote:

> System         2D API   / 3D API
> Linux          X11      / OpenGL 4.3
> Android        Canvas     / OpenGL ES 3.0
> OSX            Quartz2D / OpenGL 4.3
> iOS            Quartz2D / OpenGL ES 3.0
> Windows        Direct2D / Direct3D 11
> Windows    RT     Direct2D / Direct3D 11
>
> The reason for targeting relatively new low-level API versions is that
> by the time we actually complete the bulk of the work, they won't be new
> anymore. If anyone has a suggestion for a 2D API on Linux that has the
> ubiquity of the X11 but is easier to use, please mention it! I would
> like to have a Wayland backend but that API is still very new and not
> widely adopted. I've noticed that Android and iOS seem to have many
> options for 2D graphics, none of which I've had a chance to evaluate
> rigorously, any recommendations would be appreciated.

The choice of X11 (as it is generally used now) / Wayland seems to be the wrong layer of abstraction to me.  While X11 has drawing privimitives, my understanding is that they are generally not used. This is one of the motivating reasons for developing Wayland. Applications draw their content, then send it to X to display on the screen.  Wayland is designed around this path.  Choosing X11/Wayland as a backend is fine, but it would require that there be something filling up the framebuffer (Cairo, OpenGL, whatever).  On the other hand, choosing a renderer (Cairo, OpenGL...) doesn't specify how the content gets to the screen, so I think there's really 2 choices here: rendering backend and windowing backend.  The 3D API will still need to depend on X11/Wayland to get a window on screen.

I have no knowledge of how input works in either X11 or Wayland.

Writing Aurora to render to some kind of buffer is future-proof enough against Wayland, I think.  Likely, the initial set-up and input would have to be rewritten, but the rest would be OK.

Caveat: I'm only ~80% sure about all of this.

My GPU only supports OpenGL 3.x... maybe it's getting old.

Paul

On Sunday, 19 January 2014 at 17:44:57 UTC, ponce wrote:
> I think you should target D3D9 instead of D3D11 on Windows.

I have to disagree, I doubt it that Aurora will use D3D11-only features, I imagine any gpu that supports Feature Level 9 will be fine, the only requirement for user is to have OS newer than Windows XP.

On Sunday, 19 January 2014 at 03:38:30 UTC, Adam Wilson wrote:
> The choice that I would like to clarify is that Aurora will be a retained mode API. I understand that this is not the best choice for speed and that not everyone will be happy with this choice. However, retained mode API's are typically much higher-level, which will make it easier for developers that are unfamiliar with writing graphics code to express their intent.

What kind of retained mode API is being considered?

Is this indicating a possible change of direction in favour of a scene graph model?

On Sunday, 19 January 2014 at 03:38:30 UTC, Adam Wilson wrote:
>...
>
> The choice that I would like to clarify is that Aurora will be a retained mode API. I understand that this is not the best choice for speed and that not everyone will be happy with this choice. However, retained mode API's are typically much higher-level, which will make it easier for developers that are unfamiliar with writing graphics code to express their intent. Given the stated goal of Aurora I feel that this is the best choice.
>
>...

I am not sure why you feel the need to be one way or the other, why can't aurora support both retained and immediate mode style graphics. From what I can tell, all of the proposed back ends will be immediate mode, so why not just first build nice immediate mode api over the back ends and then build the retained mode on top of that? Both can be exposed to the end user as different ways to get the same thing done. One is not better(or easier) than the other, just suited for different things.

On Sun, 19 Jan 2014 14:35:29 -0800, Tofu Ninja <emmons0@purdue.edu> wrote:

> On Sunday, 19 January 2014 at 03:38:30 UTC, Adam Wilson wrote:
>> ...
>>
>> The choice that I would like to clarify is that Aurora will be a retained mode API. I understand that this is not the best choice for speed and that not everyone will be happy with this choice. However, retained mode API's are typically much higher-level, which will make it easier for developers that are unfamiliar with writing graphics code to express their intent. Given the stated goal of Aurora I feel that this is the best choice.
>>
>> ...
>
> I am not sure why you feel the need to be one way or the other, why can't aurora support both retained and immediate mode style graphics. From what I can tell, all of the proposed back ends will be immediate mode, so why not just first build nice immediate mode api over the back ends and then build the retained mode on top of that? Both can be exposed to the end user as different ways to get the same thing done. One is not better(or easier) than the other, just suited for different things.
>

Actually the design I've been working on passes a retained mode data structure to the backend. This gives the backend as much  flexibility as possible to render the command as best as possible given the capabilities of the API the backend is using. But doing it this precludes exposing an immediate mode. The best we could do here is expose a rendering context but it's just going to be a void pointer since the API can't expose the API specific low-level context. Aurora must not leak any low-level backend details to the front-end since that would violate the encapsulation of the low-level API.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator

On Sun, 19 Jan 2014 13:31:08 -0800, Ola Fosheim Grøstad <ola.fosheim.grostad+dlang@gmail.com> wrote:

> On Sunday, 19 January 2014 at 03:38:30 UTC, Adam Wilson wrote:
>> The choice that I would like to clarify is that Aurora will be a retained mode API. I understand that this is not the best choice for speed and that not everyone will be happy with this choice. However, retained mode API's are typically much higher-level, which will make it easier for developers that are unfamiliar with writing graphics code to express their intent.
>
> What kind of retained mode API is being considered?
>
> Is this indicating a possible change of direction in favour of a scene graph model?

I am not sure yet, probably a scene graph though or some hybrid thereof. They have the advantage of being easy to understand and use.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator

On Sun, 19 Jan 2014 11:47:11 -0800, Paul O'Neil <redballoon36@gmail.com> wrote:

> On 01/18/2014 10:38 PM, Adam Wilson wrote:
>
>> System         2D API   / 3D API
>> Linux          X11      / OpenGL 4.3
>> Android        Canvas     / OpenGL ES 3.0
>> OSX            Quartz2D / OpenGL 4.3
>> iOS            Quartz2D / OpenGL ES 3.0
>> Windows        Direct2D / Direct3D 11
>> Windows    RT     Direct2D / Direct3D 11
>>
>> The reason for targeting relatively new low-level API versions is that
>> by the time we actually complete the bulk of the work, they won't be new
>> anymore. If anyone has a suggestion for a 2D API on Linux that has the
>> ubiquity of the X11 but is easier to use, please mention it! I would
>> like to have a Wayland backend but that API is still very new and not
>> widely adopted. I've noticed that Android and iOS seem to have many
>> options for 2D graphics, none of which I've had a chance to evaluate
>> rigorously, any recommendations would be appreciated.
>
> The choice of X11 (as it is generally used now) / Wayland seems to be the wrong layer of abstraction to me.  While X11 has drawing privimitives, my understanding is that they are generally not used. This is one of the motivating reasons for developing Wayland. Applications draw their content, then send it to X to display on the screen.  Wayland is designed around this path.  Choosing X11/Wayland as a backend is fine, but it would require that there be something filling up the framebuffer (Cairo, OpenGL, whatever).  On the other hand, choosing a renderer (Cairo, OpenGL...) doesn't specify how the content gets to the screen, so I think there's really 2 choices here: rendering backend and windowing backend.  The 3D API will still need to depend on X11/Wayland to get a window on screen.
>
> I have no knowledge of how input works in either X11 or Wayland.
>
> Writing Aurora to render to some kind of buffer is future-proof enough against Wayland, I think.  Likely, the initial set-up and input would have to be rewritten, but the rest would be OK.
>
> Caveat: I'm only ~80% sure about all of this.
>
> My GPU only supports OpenGL 3.x... maybe it's getting old.
>
> Paul

As I understand it there will always be an X11/Wayland dependency to get the window but to be honest I would like to keep the usage of X11 to a minimum. I have a feeling that the 2D portions of the backend for Linux will be written in OpenGL.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator

On Sun, 19 Jan 2014 11:46:22 -0800, Matt Taylor <taylorius@gmail.com> wrote:

> On Sunday, 19 January 2014 at 17:44:57 UTC, ponce wrote:
>> On Sunday, 19 January 2014 at 03:38:30 UTC, Adam Wilson wrote:
>>>
>>> Since Aurora has a pluggable backend for rendering I feel that it will be prudent to use the low-level API's that are best suited to each platform. This will Aurora to support each platform as best as possible. As I currently can tell the following list represents
>>>
>>> System		 2D API   / 3D API
>>> Linux		  X11      / OpenGL 4.3
>>> Android		Canvas	 / OpenGL ES 3.0
>>> OSX		    Quartz2D / OpenGL 4.3
>>> iOS		    Quartz2D / OpenGL ES 3.0
>>> Windows		Direct2D / Direct3D 11
>>> Windows	RT     Direct2D / Direct3D 11
>>
>> I'm not really sold on the 2D API not written on top of the 3D API.
>> Either way, I don't think X11 should be used instead of OpenGL.
>> I think you should target D3D9 instead of D3D11 on Windows.
>
> My vote would be for selectable back ends, with OpenGL availability across the board. This opens up the possibility to do some cross platform 3d graphics with some d binding of OpenGL, using aurora's rendering context. I know it's not what aurora is for, but it would be useful, and wouldn't cost much to allow.
>
> Cheers
>
> Matt

Aurora will not be exposing any low-level API to the front-end, that would be a pretty serious encapsulation violation and could have some pretty bad consequences for the rest of the API.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator

On Monday, 20 January 2014 at 00:15:01 UTC, Adam Wilson wrote:
> I am not sure yet, probably a scene graph though or some hybrid thereof. They have the advantage of being easy to understand and use.

Sounds like a good idea as it allows you to implement a standard extensible UI on top of it. If done right you could use it for UI/HUD on top of a 3D engine too by setting the zbuffer value close to the eye.

1. draw 2D UI with close z-value or stencil
2. draw 3D beneath it/or video etc

This could be very useful for both creating media tools/editors and games. (Creating a 2D platform that allows you to do evolutionary design of a UI layered on top of other media.)