* Sources are not automatically destroyed when their context is
destroyed, i.e. sources are not "owned" by a context.
It's true that the spec (improperly) doesn't specify what happens in
this case, but in the Windows implementation we do destroy all of a
context's sources when the context is destroyed, which seems like a
friendly thing to do IMHO. We should of course clarify this in the
spec, one way or the other.
* One can have "dangling sources", i.e. sources where their associated
context has already been destroyed.
Covered by the above... I have no particular opinion on which way this
should go, although I do _like_ the idea of automatic destruction of the
sources.
INTERPRETATION 2 OF THE SPEC:
* Buffers have always exactly one associated device.
* The device associated with a buffer is the device of the current
context when alGenBuffers is called.
I like interpretation 2, for entirely selfish reasons -- I think all
implementations would have to be modified (in some cases, radically) in
order to enforce interpretation #1. I think it's very rational behavior
as well.
* Buffers are not automatically destroyed when their device is closed,
i.e. buffers are not "owned" by a device.
The current Windows implementation do a friendly destruction of a
device's buffers on destruction of the device (in debug builds we output
debug messages saying, "Hey! You failed to delete some buffers!").
Again, this is under-specified...
* One can have "dangling buffers", i.e. buffers where their associated
device has already been closed.
Addressed by the above...
* What happens when buffers are destroyed which are already queued?
If the spec allows the deletion of a buffer which is queued on a source,
then the spec needs an update. I thought that was already in there,
though... Deletion of a buffer should fail if it's being used by a source.
* One can have "dangling contexts", i.e. contexts where their
associated device has already been closed.
I don't think we should allow this. If it's not in the spec, we can add it.
Garin
|
