Specify the data model for WaveShaperNode.curve

[olivierthereaux]

Originally reported on W3C Bugzilla ISSUE-22832 Mon, 29 Jul 2013 18:50:44 GMT
Reported by Ehsan Akhgari [:ehsan]
Assigned to

We need to specify exactly what happens when you set WaveShaperNode.curve to a new array value. Roc's proposal was that we should copy the arrays set to this attribute when it the attribute is set and use the internal copies from that point on so that we don't race with those arrays being modified on the main thread. I support that proposal.

[olivierthereaux]

Original comment by Marcus Geelnard (Opera) on W3C Bugzilla. Mon, 05 Aug 2013 13:40:33 GMT

I also support copy-on-assignment, it's the clearest definition. I would prefer a specific set-method though (it would be even clearer IMO), but if backwards compat is important we could do it as suggested by ROC.

[olivierthereaux]

Original comment by Ehsan Akhgari [:ehsan] on W3C Bugzilla. Thu, 08 Aug 2013 03:24:10 GMT

I also prefer a setter method to make this clearer (and I don't think a getter method is needed at all, since content code can track the array if it needs to very easily by setting an expando property on the node, etc.)

roc, how much are you worried about the backwards compat issue here?

[cwilso]

This one is different than the other referenced issues, because it's a Float32Array that's exposed on a persistent object. It would be easier if we had a setter/getter rather than just exposing the Array. Not sure what to do here.

[padenot]

Make an internal copy, and state that subsequent modifications of the Float32Array will not modify the wave shaping curve, but re-setting it will ?

[cwilso]

yes.

On Tue, Nov 4, 2014 at 4:32 AM, Paul ADENOT notifications@github.com
wrote:

Make an internal copy, and state that subsequent modifications of the
Float32Array will not modify the wave shaping curve, but re-setting it will
?

—
Reply to this email directly or view it on GitHub
#65 (comment)
.