808876 - Implement PannerNode

Status: RESOLVED FIXED

(Core :: Web Audio, defect)

Comment 1

[(no longer active)]

Attachment: Patch (v1)

Comment 2

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 678594 [details] [diff] [review]
Patch (v1)

Can we get this spec to stop using magic numeric constants and use WebIDL enums instead (which look like strings in JS)?

r=me modulo that.

Comment 3

[(no longer active)]

I filed <https://www.w3.org/Bugs/Public/show_bug.cgi?id=19872> for the former.  The values that I have used in this patch are stolen from The Real Spec (WebKit source code) (sigh...)

I have brought up using Web IDL enums before, but crogers mostly thinks that using them doesn't have much of an advantage, plus he's worried that switching the syntax now will break existing code...

Comment 4

[(no longer active)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/ecf0c2a7cb9f

Comment 5

[Boris Zbarsky [:bzbarsky]]

It has several advantages, including less typing for actual consumers if they want to have the code readable, the inability to write unreadable code, and better ability on the part of the browser to enforce the right set of values...  How would existing code break?  Are people shipping this API unprefixed?

Comment 6

[(no longer active)]

Backed out for build bustage: https://hg.mozilla.org/integration/mozilla-inbound/rev/13d927597146

Comment 7

[(no longer active)]

(In reply to Boris Zbarsky (:bz) from comment #5)
> It has several advantages, including less typing for actual consumers if
> they want to have the code readable, the inability to write unreadable code,
> and better ability on the part of the browser to enforce the right set of
> values...  How would existing code break?  Are people shipping this API
> unprefixed?

I'm with you on all this.  Nobody has been shipping the API unprefixed, but there are various demos out there relying on webkitAudioContext which I guess Google is not quite willing to break... :(

Comment 8

[Boris Zbarsky [:bzbarsky]]

There's no real reason they can't put the right API on AudioContext but leave the thing they have on webkitAudioContext.  I understand if we can't convince them, but ... <sigh>.

Comment 9

[(no longer active)]

So, looking into the build bustage, it seems like gcc 4.4 cannot compile this program:

enum class X : unsigned short {
  x, y
};

int main() {
  X a = X::x;
  return a > X::y ? 1 : 0;
}

It just doesn't seem to have an operator> which takes arguments of the enum class file.  Therefore I think that we should up the enum class prerequisite to gcc 4.6 (which I'm sure can handle this), and just use our workaround for older gcc's.

Comment 10

[(no longer active)]

Attachment: Part 0

Comment 11

[(no longer active)]

(In reply to Boris Zbarsky (:bz) from comment #8)
> There's no real reason they can't put the right API on AudioContext but
> leave the thing they have on webkitAudioContext.  I understand if we can't
> convince them, but ... <sigh>.

This is the thread where we discussed this, FWIW: <http://lists.w3.org/Archives/Public/public-audio/2012JulSep/0805.html>

Comment 12

[(no longer active)]

Attachment: Part 0

Upon further investigation, gcc 4.5 gets this right as well.

Comment 13

[(no longer active)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/789fceea31b7
https://hg.mozilla.org/integration/mozilla-inbound/rev/8bff3d974e9e

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/789fceea31b7
https://hg.mozilla.org/mozilla-central/rev/8bff3d974e9e

Comment 15

[(no longer active)]

Mass moving Web Audio bugs to the Web Audio component.  Filter on duckityduck.