Aurora Graphics Library Initial Design Discussion

[Tofu Ninja]

On Monday, 20 January 2014 at 00:12:45 UTC, Adam Wilson wrote:
> On Sun, 19 Jan 2014 14:35:29 -0800, Tofu Ninja 
> <emmons0 at 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.

That is simply a description of a specific implementation, not a 
real reason why one would be more beneficial than the other. It 
is obvious that you want this to be as accessible as possible to 
the largest range of people posable, so I don't understand why 
you would insist on limiting the library to just one design 
style. That will only limit the overall use cases.