[Openal-devel] Faster buffer model, and more random stuff

[Sherief N. Farouk]

I'd think any new AL API should be designed after GL3. Unfortunately the 
Khronos group is taking their sweet time with it, and no one really know what 
it's like yet.

>>: Some guidelines are available in the gl pipeline newsletter.

Since AL is specificly designed to function similarly to GL, I wouldn't see 
that as very conducive.

>>: My point is, ignore the intricate details of PBO mapping. Let's focus on doing something with a GL-like INTERFACE, but with the best semantics for our target.

If your app is that strained for memory that you have to stream almost 
everything as Ogg, you'd be better off with hardware that can natively decode 
Ogg. In such a case, there's an extension which lets you load compressed Ogg 
data.

>>: And till I get such hardware, I'll work on this approach :D.

A PBO doesn't have an explicit internal format. It's data in the form of 
whatever you wrote to it. That is how it's stored in the PBO, and that's 
what's mapped. When it's used as the basis for GL function pixel data (for 
glTexImage, glReadPixels, etc), you specify the format for it, just as if you 
were using a normal RAM pointer, and GL reads/writes it to the PBO as such.

>>: Let's forget about PBOs. Let's think of the mapping proposal as if glMapBuffer never existed. Let's make a mapping function that's easiest to use while allowing most implementation side optimizations. That's why I propose convert on read/write, to isolate the user from the implementation internal format if different, and to directly map into format sink if same. Smarter things can be done when you're multithreaded.

- Sherief