search

w3c / fxtf-drafts

Mirror of https://hg.fxtf.org/drafts
https://drafts.fxtf.org/
Other
69 stars 49 forks source link

[geometry] WebGL API considerations #195

Open trusktr opened 7 years ago

trusktr commented 7 years ago

https://drafts.fxtf.org/geometry/#dom-dommatrixreadonly-tofloat32array

The following fails,

gl.uniformMatrix4fv(worldMatrixLocation, false, new Float64Array([...]))

but the following works,

gl.uniformMatrix4fv(worldMatrixLocation, false, new Float32Array([...]))

so then the following will fail

const worldMatrix = new DOMMatrix([...])
gl.uniformMatrix4fv(worldMatrixLocation, false, worldMatrix.toFloat64Array())

but the following will work

const worldMatrix = new DOMMatrix([...])
gl.uniformMatrix4fv(worldMatrixLocation, false, worldMatrix.toFloat32Array())

For example if it can accept an array,

gl.uniformMatrix4fv(worldMatrixLocation, false, [...])

then I don't see a reason for it not to be able to also accept a Float64Array and convert it into the format that it needs.

Should we revise some other APIs that would be useful with DOMMatrix to make them easier to work with? Is [geometry] is the right place for this question?

zcorpan commented 7 years ago

Happy to discuss here, but since this seems to be about changing WebGL, I suggest sending an email to public_webgl@khronos.org

dirkschulze commented 6 years ago

@trusktr We won't be able to revise APIs that are shipping already. At this point DOMMatrix seems to ship with at least 3 different, independent implementations. If there is anything that should be added then please file issues against level 2 ([geometry-2]). Unless there is something that should be done for level 1 because of future risk implementing it that justifies change existing APIs.

zcorpan commented 6 years ago

(We can just rename the tag in issues instead of filing new ones, right?)

dirkschulze commented 6 years ago

@zcorpan The spec is in CR already. So we can re-flag this issue on agreement of the contributor filing this issue or on a WG decision. In the case of the latter I am preferring to track the issue as "deferred" until a new CR was published to better keep track of raised issues after a previously published CR spec. At least as long as we did not start the work on the next level already.

tabatkins commented 6 years ago

It was labeled by zcorpan just a bit ago, you can definitely re-label it. There's no process concerns here.