Re: Sites using webkitAudioContext only

On Mon, Jun 17, 2013 at 7:30 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:

> On Mon, Jun 17, 2013 at 6:26 PM, Chris Wilson <cwilso@google.com> wrote:
>
>>   * APIs which make it possible to write inefficient code.  The
>>> synchronous decoding using AudioContext.createBuffer is the only one here
>>> that I can think of.
>>>
>>
>> Sure.  To be honest, I didn't even notice that there was a synchronous
>> decode method until you raised this.
>>
>
> Note that this I don't agree with Robert that this is not a very serious
> problem.  I've already seen some people complain about Web Audio demos to
> be slow to load or to "lock up" the browser, and in almost every case it's
> AudioContext.createBuffer, often with multi-hundred millisecond pauses on
> reasonably fast desktop machines, when loading lots of assets.  The
> situation is going to be a lot worse on mobile devices.
>

Yes.  I agree with you here; this is bad, and I think it should get
removed, despite the compat damage.  All my examples use the async method,
I believe.


> As I think I previously mentioned, I actually don't think constructors is
>> a good idea here (as most of the nodes have a direct relationship with the
>> context).
>>
>
> You can just pass in the context to the constructor, so this is not really
> a huge issue.
>

I fail to see how that's better.  You then have to define for each
constructor what happens if it's null, or invalid, ... all for what to me
is simply a stylistic change.  Am I missing some innate value of this
pattern?


> It's true that we can standardize Web Audio with these C-style creator
> APIs and things will work in practice, but we will end up with a non-webby
> API.
>

I don't think this makes Web Audio "non-webby".  I use
document.createElement() all the time.


> That's not a deal breaker, but we have the potential to fix this problem
> now if all of the three engines implementing Web Audio cooperate.
> Otherwise, I don't have a lot of hope of this being possible in a V2 of the
> spec -- that is, we might spec and implement a better API, but the damage
> of the current API will be done for everybody who has already learned and
> used the API, and it will ripple through other web developers for some time.
>

I agree that this isn't something that could be pushed to v2.  I don't see
the value of it, however.


> Other than decoding - and there, honestly, I think there's room for a
>> fuller API in the future - and possible getUserMedia, nothing leaps to mind
>> that needs Promises.
>>
>
> If we fixed all of the other issues and only left this one unresolved, I
> would be a happy man!
>

Question remains - is there a place we should be using promises?  Decoding,
I guess?


> Is there any way we can quantify and address any such issues ASAP, because
>> I think we need to be talking about large changes before small ones.
>>
>
> Hmm, not sure what you mean by quantify -- we can't do that without data,
> which we don't have.
>

I meant even just list precisely what changes we were talking about.

Blink or Webkit could ship unprefixed - but frankly, the other issues above
>> are leaving me more concerned about making that change now.
>>
>
> Which change are you referring to?
>

Making the change to support unprefixed.  If we're talking about a large
set of breaking changes, deploying that across webkit, blink, and gecko
consistently for developers would be challenging.


> Most of the carrots we can offer web developers are evangelism efforts.
> I'm not aware of any such efforts having started so far, so honestly I'm
> not holding my breath for it to suddenly start happening now.  The stick,
> however, is the prefixed implementation.  Chrome can either use that to
> unprefix AudioContext and remove the webkitAudioContext as soon as
> possible, or to make other engines conform to what it's currently
> shipping.  So far it has been using it in the latter direction.  I remember
> from the f2f conversations (please correct me if I'm wrong) that Chris
> Rogers was against removing webkitAudioContext for a long period of time
> (possibly 1-2 years if I remember the conversation correctly), which really
> worries me.
>

This all being said, I think we've talked about all of the possible
> directions we can possibly take quite extensively thus far.  Let's give
> Chris Rogers a chance to catch up with the thread and comment on it, and
> then we can discuss which path forward we should be taking.
>

To be clear, I've been having conversations with Chris about this on the
side; he's been paying attention, and I'm sure he will chime in if I say
anything he wildly disagrees with.  He's just busy.

I think I am safe in saying both Chris and I are on board with:
-removing the old names from the spec
-NOT implementing them in unprefixed AudioContext
-putting in console warnings in using them in webkitAudioContext, and
working to minimize their use in order to remove them completely.

I think we are both also agreed that we don't currently see value in
changing the creator/constructor pattern, nor where promises should be
applied, and if there are any other bikeshedding changes (is Analyser ->
Analyzer still an issue?) - I don't recall if we've specifically discussed
the sync decode issue, so maybe that's a place we should use Promises, but
it's going to be hard to remove what's there.