Aurora Graphics Library Initial Design Discussion

Adam Wilson flyboynw at gmail.com
Sun Jan 19 16:12:44 PST 2014


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.

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


More information about the Digitalmars-d mailing list