Aurora Graphics Library Initial Design Discussion

[Adam Wilson]

On Sat, 18 Jan 2014 22:02:12 -0800, Kelet <kelethunter at gmail.com> wrote:

> On Sunday, 19 January 2014 at 05:23:24 UTC, Elvis Zhou wrote:
>> https://github.com/Zoadian/aurora
>> Oops, I thought this is the official repo!! It's a new package added to  
>> code.dlang.org yesterday.
>
> Doh, I made the same mistake.
>
> On Sunday, 19 January 2014 at 03:38:30 UTC, 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
>
> My thoughts:
>
> ARM support is abysmal in D, IIRC. This rules out most of the mobile  
> devices until that situation is relieved. In the meantime, the code  
> should be tested on LDC and GDC regularly. Once ARM support is mature on  
> one of the aforementioned backend, it shouldn't be difficult to finalize  
> support.
>
> I'm not convinced of two things:
> - OpenGL should not be used for the 2D API
> - Direct3D should be a backend
>
> Ideally, 2D and 3D graphics should be a specific case of a generalized  
> system which utilizes OpenGL. Thus, there is no need for a separate  
> backend API for 2D graphics. I've done 2D in OpenGL and it was not very  
> painful, although it was not a substantial project.
>
> I've used a ton of OpenGL software on a lot of hardware running Windows  
> and never encountered a problem or major deficiency which is not present  
> in Direct3D, hence I don't know why extra effort should be expended to  
> support it as a backend.
>

It may be true of simple implementation on the same hardware but consider  
that the OpenGL API is implemented entirely by the GPU vendor, this  
invariably results in the same command producing different results in some  
cases, and the cases will change between vendors and API versions. It's a  
maddening problem because while it looks right on your GPU it might look  
different on another or it might not, this means testing on as much  
hardware as possible, which is something that will take a LOT of time as  
user reports bugs on their own hardware. See the last paragraph in this  
citation:  
http://en.wikipedia.org/wiki/Comparison_of_OpenGL_and_Direct3D#Availability

DirectX does not have this problem, granted it does so at the expense of  
cross-platform ability, but given the pluggable nature of Aurora backends  
I fail to see the harm in using DirectX given it's uniformity on at least  
Windows.

> Backends in order of importance, IMO:
> - OpenGL 2.0
> - OpenGL 2.0 ES
> - OpenGL 1.1
> - Software
> - OpenGL 4.3
>
> There are a surprising amount of people still on OpenGL 2.0 and 1.1. For  
> everything else: Software backend. It wouldn't hurt to have a 'state of  
> the art' OpenGL 4.3 backend either, but only after all else is done.
>
> However, my forays into graphics are mainly hobby game development so I  
> may be missing some elements here.
>
> Regards,
> Kelet

I picked OpenGL 4.3 primarily because it is compatible with OpenGL ES 3.0  
which will make porting to iOS/Android easier. There is nothing stopping  
Aurora from having a backend built on an older version, but keep in mind  
that Aurora's front-end sets the required features, and I don't think  
OpenGL 1.0 can meet them without a rather large assist from handmade CPU  
algorithms, which will inevitably mar performance over the newer API's.

Another backend I'd like to serious consider is AMD's Mantle API, which is  
even lower-level than OpenGL and DirectX but supposedly 45% more  
performant. There is no sense not building as much performance into Aurora  
as long as it doesn't interfere with the ease-of-use goal.

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