[openal] Ideas on an explicit context API

[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.