createBuffer() has a validation rule that mappedAtCreation buffers must have a size that's a multiple of 4. This is because when we map at creation we map the entire buffer, but mapping only allows multiples of 4 (IIRC so that data copies on map/unmap are possible, since those also have to have the copy size be a multiple of 4).

However this doesn't get validated until the device timeline, meaning the content timeline buffer object is already happily mapped - with a size that we don't normally support for mapping. The actual buffer object ends up being an invalid object, later.

We could:

1. Make no change, implementations just have to deal with this (and we should make sure these edge cases are tested well - in particular what happens on unmap).
   • Implementations can round down the size that gets mapped because getMappedRange won't actually allow accessing the rest. But this introduces quite a bit of complexity in multi-process implementation, I think.
2. Move this check to the content timeline, so createBuffer() throws an exception instead of returning a buffer object. (Kinda breaking change, turns a validation error into an exception.)
3. Round up or down the actual size of the mapping so that the mapped region is smaller/larger than the whole buffer.
4. Round down and remove the validation check so that you can actually create a buffer this way (just can't initialize the last few bytes).

I think I prefer 2.