Allow non-null FLOAT_32_UNSIGNED_INT_24_8_REV uploads. #1678
Conversation
| @@ -1376,6 +1375,7 @@ <h2 class="no-toc">Table of contents</h2> | |||
| <tr><td>Uint32Array</td><td>UNSIGNED_INT_24_8</td></tr> | |||
| <tr><td>Uint16Array</td><td>HALF_FLOAT</td></tr> | |||
| <tr><td>Float32Array</td><td>FLOAT</td></tr> | |||
| <tr><td>ArrayBuffer</td><td>FLOAT_32_UNSIGNED_INT_24_8_REV</td></tr> | |||
There was a problem hiding this comment.
ArrayBuffer is not compatible with the ArrayBufferView argument in the IDL. This change does not look good as is.
I am dubious that the added value of supporting uploads for this texture type is worth the perturbation to the IDL. Another overload would have to be added in order to support just this texture type -- assuming we don't want to use one of the other existing ArrayBufferView types for it (which would probably be confusing). The best fit would be either Float32Array or Uint32Array.
|
From #2667 (comment):
Is it still expected? If so, this PR could be extended to cover that issue. |
|
We do still aim to make that change, but right now all browser vendors are making a push to pass the top-of-tree conformance suite before taking the next snapshot. It's not a good time right now to make significant API changes - and this would be one. |
|
@kenrussell @jdashg |
|
Yes, some day. :) Thanks for the bump! |
It sounds like the only reason we disabled this is because there's no good match for the type of the ArrayBufferView to be uploaded. We do seem to allow other depth/stencil upload types.
We should just let people upload it if they manage to marshal it, perhaps just allowing ArrayBuffer here.