[openal] Ideas on an explicit context API

[hypatia.sva at posteo.eu]

Hello,

is this kind of what you wanted?

https://github.com/hypatia-of-sva/alad/blob/main/openal-explicit-polyfill.h

It's currently no better in terms of performance, as its temporarily 
swapping contexts, but I would be interested if that is kind of the 
semantics you are interested in or if it's different.
I also added the possibility of having multiple listeners per context. I 
don't know if thats truely necessary for anything, but since it's 
trivial to add I thought it might as well be there to differentiate 
which function
changes which state information.

Hypatia of Sva.

Am 24.04.2023 09:37 schrieb Chris Robinson:
> On 4/23/23 21:47, Ryan C. Gordon wrote:
>> 
>>> that for every
>>> 
>>> alFoo(...) / alFooEXT(...)
>>> 
>>> function, there would be a matching
>>> 
>>> alFooExplicit(ALCcontext*, ...) / alFooExplicitEXT(ALCcontext*, ...)
>> 
>> I like this idea a lot. All the existing entry points just become 
>> simple wrappers:
>> 
>>      void alFoo(ALint bar) {
>>          alFooExplicit(alcGetCurrentContext(), bar);
>>      }
>> 
>> ...and the existing implementation moves to the Explicit version, and 
>> then it's just a matter of cleaning out references to the current 
>> context from them.
> 
> More or less, yeah. Though depending on whether these new functions
> check the validity of the current context or not, and whether they're
> considered thread-safe with regard to destruction (i.e. if one thread
> destroys a context at the same time another thread tries to call
> something with it), that specific example could result in redundant
> validation checking. It may end up more like
> 
> void _alFooImpl(ContextRef context, ALint bar);
> 
> void alFoo(ALint bar) {
>     _alFooImpl(GetCurrentContextRef(), bar);
> }
> void alFooExplicit(ALcontext *context, ALint bar) {
>     _alFooImpl(ValidateContext(context), bar);
> }
> 
> where GetCurrentContextRef and ValidateContext are internal functions
> that safely return a reference-counted context handle, ensuring it
> won't be deleted while in scope.
> 
>> I don't love the word "Explicit" for this, but that's a minor gripe. 
>> If I come up with a different word, I'll suggest it here for 
>> discussion.
> 
> I'm certainly open to alternative names, especially if they're
> shorter. I remember OpenGL having the GL_ARB_direct_state_access
> extension to avoid having to set an object as current, or "bind" it,
> to modify in a similar way. E.g.
> 
> glBindBuffer(type, bufferid);
> glBufferData(type, ...); // modifies bufferid
> 
> became
> 
> glNamedBufferData(bufferid, ...);
> 
> OpenAL already does this as standard for sources/buffers/etc, but
> maybe this could be "direct context access", using the Direct suffix
> as in alFooDirect(context, ...)?
> 
>> The nasty part of this is going to be how to deal with extensions. Do 
>> we say there's a finite list of known extensions right now, and we'll 
>> list them all out as having Explicit equivalents if the AL supports 
>> both Explicit contexts and that extension, but the app is on its own 
>> if an extension isn't included and doesn't mention its interaction 
>> with Explicit context support?
> 
> Ideally it would include all current and future extensions that have
> non-Explicit AL functions. An implementation that supports Explicit
> contexts shouldn't have an issue providing Explicit context functions
> for other extensions it supports without needing them to be...
> explicitly mentioned, since it's a generalized concept.
> 
> Admittedly I don't know how to word it in a way that would be clear in
> that regard, but the usefulness would be limited if only some
> extensions are guaranteed to work. Maybe it won't be a problem to
> mention new functions only for existing extensions when supported
> alongside Explicit contexts like you suggest, then ensure future
> extensions specifically mention Explicit context functions as needed.
> _______________________________________________
> openal mailing list
> openal at openal.org
> http://openal.org/mailman/listinfo/openal