Closed
Bug 1200579
Opened 9 years ago
Closed 9 years ago
Stop copying AudioParam timelines
Categories
(Core :: Web Audio, defect, P1)
Core
Web Audio
Tracking
()
RESOLVED
FIXED
mozilla44
Tracking | Status | |
---|---|---|
firefox44 | --- | fixed |
People
(Reporter: padenot, Assigned: padenot)
References
(Blocks 2 open bugs)
Details
Attachments
(3 files, 2 obsolete files)
(deleted),
patch
|
karlt
:
feedback+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
karlt
:
review+
|
Details | Diff | Splinter Review |
It's highly ineffective. Let's consider this benchmark [0], that implements a very classic toy substractive synth.
An inverse profiler call tree shows this:
5.1%: nsTArray<AudioTimelineEvent>::AppendElements
2.2%: nsTArray<AudioTimelineEvent>::ReplaceElementsAt
1.4%: nsTArray<AudioTimelineEvent>::~nsTArray
Instead, we should:
- Keep a range list of period of time where a curve is present, so we can throw synchronously on the main thread (since per spec, we have to throw if authors try to set an event during a curve). We can do other checks without knowing the state of the timeline
- Send just the single event to the MSG thread using a ControlMessage
- Append this event to the AudioNodeEngine's timeline
This should get rid of most nsTArray<AudioTimelineEvent>::* in the profiles.
[0]: https://github.com/padenot/webaudio-benchmark/blob/gh-pages/benchmarks.js#L287
Assignee | ||
Comment 1•9 years ago
|
||
(In reply to Paul Adenot (:padenot) from comment #0)
> - Keep a range list of period of time where a curve is present, so we can
> throw synchronously on the main thread (since per spec, we have to throw if
> authors try to set an event during a curve). We can do other checks without
> knowing the state of the timeline
I was wrong on this one, we need the full timeline because we need to check whether the previous value is zero for an exponential ramp.
Either we need to duplicate the timeline, or we need to lock. Locking is not ideal (it's conceptually against the architecture of the MSG), but looks like it would be more efficient. It also potentially has the advantage of lowering the time between the JavaScript call and reflecting it in the msg-side timeline, but I might have other plans to address that.
For now I'm going to go with the duplication. Then I'll implement the lock (I think it's easier), and do some testing/benchmarking.
Assignee | ||
Updated•9 years ago
|
Blocks: webaudioperf_parity
Comment 2•9 years ago
|
||
Locks would mean that "immediate" changes would not be processed as a transaction with other timeline changes or other graph changes.
IIRC the main thread needs the timeline to for the value getter, which would make
duplicating the timeline necessary. I haven't looked at the code, but perhaps more culling of old events can be done.
Assignee | ||
Comment 3•9 years ago
|
||
So in fact, the timeline is already present twice in memory, since we don't clear out the previous data, I didn't know the code enough when I started this, and I had wrong assumption.
This allow us to implement `BiquadFilterNode.getFrequencyResponse` properly. We could implement synchronous querying of the value (the `AudioParam.value` getter) in the same way.
And indeed culling of old events makes sense even on the main thread.
Assignee | ||
Comment 4•9 years ago
|
||
We stop copying and just send AudioTimelineEvents to the MSG, using the same
message-passing mechanism we use for the rest of the main thread -> MSG
communication.
A couple notable points:
- Checking that an event is valid now only occurs on the main thread. When
sent, it is considered valid for insertion and is just inserted. This is ok
because the two timeline are exact copyies (except MSG's copy pruning, but we
only prune behind the AudioContext.currentTime anyways)
- We now have to send changes for the `value` attribute of the `AudioParam` and
the fact that the input of an `AudioParam` is a node through the same
`AudioTimelineEvent`. We take advantage of the fact that there cannot be both a
curve and a stream in the same event, so we can safely use an union here.
- Conversion between time in seconds (main thread) and time in MSG ticks (MSG
thread) happens right before the insertion in the MSG `AudioParamTimeline`. We
now use exclusively the getter and not the union, so it's safer. Because we
send events and not the full timeline each time we don't have to convert all the
events each time.
Attachment #8659124 -
Flags: review?(karlt)
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → padenot
Status: NEW → ASSIGNED
Assignee | ||
Comment 5•9 years ago
|
||
This is all the (mechanical) changes to convert the nodes to the new way of
sending timeline events to the MSG.
Attachment #8659127 -
Flags: review?(karlt)
Assignee | ||
Comment 6•9 years ago
|
||
Comment 7•9 years ago
|
||
Comment on attachment 8659124 [details] [diff] [review]
Stop copying AudioParam timelines. r=
The approach looks good thanks. A few little things.
>+ MediaStream* mStream;
Please document what ensures that mStream remains alive, or keep a reference.
> private:
> static bool IsValid(double value)
> {
> return mozilla::IsFinite(value);
> }
>+private:
>+ // This member is accessed using the `Time` method, for safety.
Gecko convention is to use "private:" only as necessary (once), rather than
for each member.
>- void InsertEvent(const AudioTimelineEvent& aEvent, ErrorResult& aRv)
>+ bool ValidateEvent(AudioTimelineEvent& aEvent,
>+ ErrorResult& aRv)
> {
>+ MOZ_ASSERT(NS_IsMainThread());
>+
>+ if (!WebAudioUtils::IsTimeValid(aEvent.template Time<double>()) ||
>+ !WebAudioUtils::IsTimeValid(aEvent.mTimeConstant)) {
>+ aRv.Throw(NS_ERROR_DOM_SYNTAX_ERR);
>+ return false;
>+ }
>+
> if (!aEvent.IsValid()) {
> aRv.Throw(NS_ERROR_DOM_SYNTAX_ERR);
>- return;
>+ return false;
Is there a distinction between timeline-independent checks in ValidateEvent()
and those in IsValid()? Could these all be on an AudioTimelineEvent method?
>+ const AudioTimelineEvent* GetPreviousEvent(double aTime) const
Can this remain private?
>-private:
>+protected:
> // This is a sorted array of the events in the timeline. Queries of this
Please remove the "protected:" line to leave this private.
There is no need to export these to derived classes AFAICS.
>+++ b/dom/media/webaudio/AudioNode.h
>+#include "AudioEventTimeline.h"
>
> namespace mozilla {
>
> namespace dom {
>
> class AudioContext;
> class AudioBufferSourceNode;
> class AudioParam;
>@@ -218,18 +219,18 @@ private:
>+ static void SendTimelineEventToStream(AudioNode* aNode, uint32_t aIndex,
>+ const dom::AudioTimelineEvent& aEvent);
Forward declare instead of including in headers, where possible.
Otherwise includes get out of control.
Here, use "struct AudioTimelineEvent" like the AudioParam declaration.
Similarly in AudioNodeEngine.h, AudioNodeStream.h.
>- virtual void SetTimelineParameter(uint32_t aIndex,
>- const dom::AudioParamTimeline& aValue,
>- TrackRate aSampleRate)
>+ virtual void SendTimelineEvent(uint32_t aIndex,
>+ dom::AudioTimelineEvent& aValue)
All the comparable AudioNodeEngine and AudioNodeStream methods are called
Set*. "SetTimelineEvent" wouldn't make much sense, so I like
SendTimelineEvent on the AudioNodeStream, but its not so appropriate on the
engine. Can you call this "AudioNodeEngine::RecvTimelineEvent" or similar,
please?
(Another option is "AddTimelineEvent", which could be used for both
stream and engine methods, but "Recv" does more to imply that the engine is
assuming ownership and modifying the event through the non-const reference.)
>+ // This sends a single event to the timeline, on the MSG thread side.
No comma ',' because it is the timeline that is on the MSG thread,
not the send.
>- // We override SetValueCurveAtTime to convert the Float32Array to the wrapper
>- // object.
>- void SetValueCurveAtTime(const Float32Array& aValues, double aStartTime, double aDuration, ErrorResult& aRv)
>+ // We override SetValueCurveAtTime to convert the Float32Array to the wrapper
>+ // object.
>+ void SetValueCurveAtTime(const Float32Array& aValues, double aStartTime, double aDuration, ErrorResult& aRv)
Indentation.
Other methods call InsertEvent(), but SetValueCurveAtTime() doesn't. That
would be a change in the behavior of the method. Calling InsertEvent seems
the appropriate behavior so that the main thread can calculate the intrinsic
value.
The validate/insert/callback pattern is frequent. A helper method would tidy
up a bit and ensure that the same thing happens in each case.
SetValue() calls InsertEvent() but CancelScheduledValues() chains up to the base
class method. Can CancelScheduledValues follow the pattern of the others
and use the helper.
Some methods are calling DOMTimeToStreamTime() on the event time. Others are
not. I expect the helper can also create the event and do the conversion.
>- if (!WebAudioUtils::IsTimeValid(aStartTime)) {
>- aRv.Throw(NS_ERROR_DOM_NOT_SUPPORTED_ERR);
The error code is changing to NS_ERROR_DOM_SYNTAX_ERR.
I assume that's not intentional.
Similarly elsewhere.
>+ // Remove some events on the main thread copy.
>+ AudioEventTimeline::CancelScheduledValues(DOMTimeToStreamTime(aStartTime));
>+
>+ AudioTimelineEvent event(AudioTimelineEvent::Cancel, aStartTime, 0.0f);
Missing DOMTimeToStreamTime().
>+ MOZ_ASSERT(!aSource || aSource->SampleRate() == aDest->SampleRate());
>+ aEvent.SetTimeInTicks(
Indentation.
>- * Converts AudioParamTimeline floating point time values to tick values
>- * with respect to a source and a destination AudioNodeStream.
>+ * Converts an AudioTimelineEvent point time values to tick values
>+ * with respect to a destination AudioNodeStream.
Please keep "floating".
Either "Converts an AudioTimelineEvent's floating point time values"
or "Converts AudioTimelineEvent floating point time values".
>+++ b/dom/media/webaudio/compiledtest/TestAudioEventTimeline.cpp
>+#include "MainThreadUtils.h"
Why this change?
Attachment #8659124 -
Flags: review?(karlt)
Attachment #8659124 -
Flags: review-
Attachment #8659124 -
Flags: feedback+
Comment 8•9 years ago
|
||
Comment on attachment 8659127 [details] [diff] [review]
Changes in all the AudioNode implementations. r=
Please fold this into the other patch because it won't compile without these
changes.
The best improvement to readability from dividing up the changes would be to
move (and make public) InsertEvent() and ValidateEvent() in a separate patch
with no other changes.
>+++ b/dom/media/webaudio/BiquadFilterNode.h
>@@ -5,16 +5,17 @@
> * file, You can obtain one at http://mozilla.org/MPL/2.0/. */
>
> #ifndef BiquadFilterNode_h_
> #define BiquadFilterNode_h_
>
> #include "AudioNode.h"
> #include "AudioParam.h"
> #include "mozilla/dom/BiquadFilterNodeBinding.h"
>+#include "AudioEventTimeline.h"
Forward declare.
Attachment #8659127 -
Flags: review?(karlt) → feedback+
Assignee | ||
Comment 9•9 years ago
|
||
(In reply to Karl Tomlinson (ni?:karlt) from comment #7)
> Comment on attachment 8659124 [details] [diff] [review]
> Stop copying AudioParam timelines. r=
>
> The approach looks good thanks. A few little things.
>
> >+ MediaStream* mStream;
>
> Please document what ensures that mStream remains alive, or keep a reference.
I've added a strong reference. I also had to mock MediaStream in the unit test.
> >- void InsertEvent(const AudioTimelineEvent& aEvent, ErrorResult& aRv)
> >+ bool ValidateEvent(AudioTimelineEvent& aEvent,
> >+ ErrorResult& aRv)
> > {
> >+ MOZ_ASSERT(NS_IsMainThread());
> >+
> >+ if (!WebAudioUtils::IsTimeValid(aEvent.template Time<double>()) ||
> >+ !WebAudioUtils::IsTimeValid(aEvent.mTimeConstant)) {
> >+ aRv.Throw(NS_ERROR_DOM_SYNTAX_ERR);
> >+ return false;
> >+ }
> >+
> > if (!aEvent.IsValid()) {
> > aRv.Throw(NS_ERROR_DOM_SYNTAX_ERR);
> >- return;
> >+ return false;
>
> Is there a distinction between timeline-independent checks in ValidateEvent()
> and those in IsValid()? Could these all be on an AudioTimelineEvent method?
So, we need to return very specific DOM errors depending on certain values in the event. We can't use ErrorResult in AudioTimelineEvent because it's not templated on ErrorResult, and we don't pull in the DOM's ErrorResult in the cppunittest.
I've consolidated everything in the ValidateEvent method instead. At least, all the checks are in the sample place now.
> >+ const AudioTimelineEvent* GetPreviousEvent(double aTime) const
>
> Can this remain private?
Yes. I'm about to remove it, but I've made it private for now.
> >-private:
> >+protected:
> > // This is a sorted array of the events in the timeline. Queries of this
>
> Please remove the "protected:" line to leave this private.
> There is no need to export these to derived classes AFAICS.
Sorry, this was from a previous iteration of the patch.
> >- virtual void SetTimelineParameter(uint32_t aIndex,
> >- const dom::AudioParamTimeline& aValue,
> >- TrackRate aSampleRate)
> >+ virtual void SendTimelineEvent(uint32_t aIndex,
> >+ dom::AudioTimelineEvent& aValue)
>
> All the comparable AudioNodeEngine and AudioNodeStream methods are called
> Set*. "SetTimelineEvent" wouldn't make much sense, so I like
> SendTimelineEvent on the AudioNodeStream, but its not so appropriate on the
> engine. Can you call this "AudioNodeEngine::RecvTimelineEvent" or similar,
> please?
Yes.
> >- // We override SetValueCurveAtTime to convert the Float32Array to the wrapper
> >- // object.
> >- void SetValueCurveAtTime(const Float32Array& aValues, double aStartTime, double aDuration, ErrorResult& aRv)
> >+ // We override SetValueCurveAtTime to convert the Float32Array to the wrapper
> >+ // object.
> >+ void SetValueCurveAtTime(const Float32Array& aValues, double aStartTime, double aDuration, ErrorResult& aRv)
>
> Indentation.
>
> Other methods call InsertEvent(), but SetValueCurveAtTime() doesn't. That
> would be a change in the behavior of the method. Calling InsertEvent seems
> the appropriate behavior so that the main thread can calculate the intrinsic
> value.
Yes, that's a mistake.
> The validate/insert/callback pattern is frequent. A helper method would tidy
> up a bit and ensure that the same thing happens in each case.
I've done that. `CancelScheduledValue()` and `SetValue()` should not insert an event on the same thread. Instead, they should modify the timeline on the main thread and then send the event to the MSG thread.
> SetValue() calls InsertEvent() but CancelScheduledValues() chains up to the
> base
> class method. Can CancelScheduledValues follow the pattern of the others
> and use the helper.
This is a mistake, per above.
> Some methods are calling DOMTimeToStreamTime() on the event time. Others are
> not. I expect the helper can also create the event and do the conversion.
Done. The methods that are creating a special event (SetValue, CancelScheduledValue, Stream), have not been moved to the helper so that the method itself is simple.
>
> >- if (!WebAudioUtils::IsTimeValid(aStartTime)) {
> >- aRv.Throw(NS_ERROR_DOM_NOT_SUPPORTED_ERR);
>
> The error code is changing to NS_ERROR_DOM_SYNTAX_ERR.
> I assume that's not intentional.
> Similarly elsewhere.
This is all about to change (in bug 1204883). For, I mostly care about the tests passing.
> >+++ b/dom/media/webaudio/compiledtest/TestAudioEventTimeline.cpp
>
> >+#include "MainThreadUtils.h"
>
> Why this change?
The test does not compile anymore otherwise, I've added a number of threading assertion using `NS_IsMainThread()` in `AudioEventTimeline.h` in `AudioTimelineEvent::Time()`.
Assignee | ||
Comment 10•9 years ago
|
||
Here is an interdiff for the first patch.
Assignee | ||
Comment 11•9 years ago
|
||
This is everything folded into one patch.
Attachment #8661231 -
Flags: review?(karlt)
Assignee | ||
Updated•9 years ago
|
Attachment #8659124 -
Attachment is obsolete: true
Comment 12•9 years ago
|
||
Comment on attachment 8661231 [details] [diff] [review]
Stop copying AudioParam timelines. r=
Please don't move GetPreviousEvent().
That is adding noise to the patch and making it harder to review.
I haven't yet reviewed the InsertEvent() code moved in this version.
>* * *
>Bug 1200579 - Changes in all the AudioNode implementations. r=
>
>This is all the changes to convert the nodes to the new way of sending timeline
>event to the MSG.
This can be removed.
> AudioTimelineEvent(const AudioTimelineEvent& rhs)
> {
> PodCopy(this, &rhs, 1);
> if (rhs.mType == AudioTimelineEvent::SetValueCurve) {
> SetCurveParams(rhs.mCurve, rhs.mCurveLength);
> }
> }
>
> ~AudioTimelineEvent()
> {
> if (mType == AudioTimelineEvent::SetValueCurve) {
> delete[] mCurve;
> }
> }
These are not dealing with mStream appropriately when mType == Stream.
mStream's destructor needs to be run explicitly when appropriate.
> template <>
> inline double AudioTimelineEvent::Time<double>() const
> {
> MOZ_ASSERT(!mTimeIsInTicks);
>+ MOZ_ASSERT(NS_IsMainThread());
> return mTime;
Used off main thread from ConvertAudioTimelineEventToTicks().
>+ // Validate the event itself
>+ if (!WebAudioUtils::IsTimeValid(aEvent.template Time<double>()) ||
>+ !WebAudioUtils::IsTimeValid(aEvent.mTimeConstant)) {
>+ aRv.Throw(NS_ERROR_DOM_SYNTAX_ERR);
>+ return false;
>+ }
>+ bool timeValueValid = IsValid(aEvent.template Time<double>()) &&
>+ IsValid(aEvent.mValue) &&
>+ IsValid(aEvent.mTimeConstant) &&
>+ IsValid(aEvent.mDuration);
WebAudioUtils::IsTimeValid() is stricter than IsValid(), so no need to test
Time() and mTimeConstant again.
>+++ b/dom/media/webaudio/AudioNodeEngine.h
>@@ -5,16 +5,17 @@
> * file, You can obtain one at http://mozilla.org/MPL/2.0/. */
> #ifndef MOZILLA_AUDIONODEENGINE_H_
> #define MOZILLA_AUDIONODEENGINE_H_
>
> #include "AudioSegment.h"
> #include "mozilla/dom/AudioNode.h"
> #include "mozilla/MemoryReporting.h"
> #include "mozilla/Mutex.h"
>+#include "AudioEventTimeline.h"
Forward declare.
>+++ b/dom/media/webaudio/AudioParam.h
>@@ -10,28 +10,29 @@
> #include "AudioParamTimeline.h"
> #include "nsWrapperCache.h"
> #include "nsCycleCollectionParticipant.h"
> #include "nsAutoPtr.h"
> #include "AudioNode.h"
> #include "mozilla/dom/TypedArray.h"
> #include "WebAudioUtils.h"
> #include "js/TypeDecls.h"
>+#include "AudioEventTimeline.h"
Already included through AudioParamTimeline.h.
>@@ -44,87 +45,103 @@ public:
>
> double DOMTimeToStreamTime(double aTime) const
> {
> return mNode->Context()->DOMTimeToStreamTime(aTime);
> }
>
> virtual JSObject* WrapObject(JSContext* aCx, JS::Handle<JSObject*> aGivenProto) override;
>
>+ void EventInsertionHelper(ErrorResult& aRv,
private or protected. (This class is final.)
>+ InsertEvent<double>(event);
AudioParamTimeline::InsertEvent to skip the unnecessary Cancel/SetValue/Stream
handling.
(In reply to Paul Adenot (:padenot) from comment #9)
> (In reply to Karl Tomlinson (ni?:karlt) from comment #7)
> > >+#include "MainThreadUtils.h"
> >
> > Why this change?
>
> The test does not compile anymore otherwise, I've added a number of threading
> assertion using `NS_IsMainThread()` in `AudioEventTimeline.h` in
> `AudioTimelineEvent::Time()`.
That should go in AudioTimelineEvent.h then.
It's counter-intuitive for callers to need to include headers for their
callees.
Attachment #8661231 -
Flags: review?(karlt) → review-
Comment 13•9 years ago
|
||
Comment on attachment 8661231 [details] [diff] [review]
Stop copying AudioParam timelines. r=
>+ // Remove some events on the main thread copy.
>+ AudioEventTimeline::CancelScheduledValues(DOMTimeToStreamTime(aStartTime));
>+
>+ AudioTimelineEvent event(AudioTimelineEvent::Cancel,
>+ DOMTimeToStreamTime(aStartTime), 0.0f);
DOMTimeToStreamTime() is non-trivial so call the method only once.
Either read from the event or use a local variable.
Assignee | ||
Comment 14•9 years ago
|
||
Updated•9 years ago
|
Rank: 10
Priority: -- → P1
Comment 15•9 years ago
|
||
In the copy constructor, need to skip the PodCopy when mType is Stream and use placement new instead of mStream.operator=.
http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=556
may be helpful.
Comment 16•9 years ago
|
||
Actually, I guess the PodCopy is ok with placement new after the copy.
Assignee | ||
Comment 17•9 years ago
|
||
Comment 18•9 years ago
|
||
Perhaps it is easier manually refcount a MediaStream* AudioTimelineEvent::mStream than using placement new on a nsRefPtr<MediaStream>.
Assignee | ||
Comment 19•9 years ago
|
||
Assignee | ||
Comment 20•9 years ago
|
||
Comment 21•9 years ago
|
||
https://hg.mozilla.org/try/rev/9a1c72aad2da has a placement new solution, so that mType is not used uninitialized in the copy constructor,
but it seems that the MSVC version doesn't have support for these unions.
https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code
https://treeherder.mozilla.org/#/jobs?repo=try&revision=00e50d1d9a9e
Assignee | ||
Comment 22•9 years ago
|
||
I think I'll use inheritance to have tighter instances for the `AudioTimelineEvent` and compile everywhere. We can save some bytes, and this is the kind of class that gets instantiated a lot and where each instance is duplicated, on top of that.
I've got green tries with patches resembling yours in comment 21, but refactoring this so that it's tighter and looks better is probably not hard so I'll do it before re-requesting review, in a separate patch.
Assignee | ||
Comment 23•9 years ago
|
||
In fact we would need to change a bunch of things that we are changing in bug 1184057, and I expect to get to it soon, so I'll make the event smaller later later, and put mStream out of the union for now.
I've taken you patch in comment 21, it's better than what I had.
Assignee | ||
Comment 24•9 years ago
|
||
This has your patch to the copy constructor, and all the comments addressed.
Attachment #8664346 -
Flags: review?(karlt)
Assignee | ||
Updated•9 years ago
|
Attachment #8661231 -
Attachment is obsolete: true
Comment 25•9 years ago
|
||
Comment on attachment 8664346 [details] [diff] [review]
Stop copying AudioParam timelines. r=
(In reply to Paul Adenot (:padenot) from comment #23)
> In fact we would need to change a bunch of things that we are changing in
> bug 1184057, and I expect to get to it soon, so I'll make the event smaller
> later later, and put mStream out of the union for now.
Moving it out of the union makes sense for now, but see below for one issue.
Inheritance works well for individually heap allocated classes, but
AudioTimelineEvent has many stack/member allocations. I think it would be
best to avoid allocating each event on the heap individually, and so I suspect
a union with manual ref-counting of bare pointers will provide the best long
term solution.
> ~AudioTimelineEvent()
> {
> if (mType == AudioTimelineEvent::SetValueCurve) {
> delete[] mCurve;
>+ } else if (mType == AudioTimelineEvent::Stream) {
>+ mStream.~nsRefPtr<MediaStream>();
> }
> }
Don't add the new code here. Now that mStream is not part of a union, this is
not necessary, and I think it will cause problems because mStream's destructor
should run after the AudioTimelineEvent destructor. Running the destructor
twice will release the reference twice.
(In reply to Karl Tomlinson (ni?:karlt) from comment #12)
> >* * *
> >Bug 1200579 - Changes in all the AudioNode implementations. r=
> >
> >This is all the changes to convert the nodes to the new way of sending timeline
> >event to the MSG.
>
> This can be removed.
To be clear, I wasn't asking for the whole commit message to be removed, just
the quoted part left over from the fold. However, I guess much of the comment
may be obsolete now anyway.
>+ // Validate the event itself
>+ if (!WebAudioUtils::IsTimeValid(aEvent.template Time<double>()) ||
>+ !WebAudioUtils::IsTimeValid(aEvent.mTimeConstant)) {
>+ aRv.Throw(NS_ERROR_DOM_SYNTAX_ERR);
>+ return false;
>+ }
>- if (!WebAudioUtils::IsTimeValid(aStartTime)) {
>- aRv.Throw(NS_ERROR_DOM_NOT_SUPPORTED_ERR);
There are two issues with these changes:
1) AudioEventTimeline has these double times after DOMTimeToStreamTime
conversion and so they may be negative.
This change makes the testcase in bug 864171 throw.
I don't like these DOMTimeToStreamTime conversions anyway, so if you are
happy with the fix that I'll upload to that bug, then we can ignore this.
2) browser/devtools/webaudioeditor/test/browser_callwatcher-02.js is failing.
I assume that is due to these changes.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=00e50d1d9a9e
For now, I would leave the checks in AudioParam.h and make minimal changes to
the checks in AudioEventTimeline.h.
Attachment #8664346 -
Flags: review?(karlt) → review+
Assignee | ||
Comment 26•9 years ago
|
||
Comment 27•9 years ago
|
||
Comment 28•9 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox44:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
You need to log in
before you can comment on or make changes to this bug.
Description
•