[Bug 19975] Promote data and timestamp onmessage/MIDIEvent, get rid of MIDIMessage altogether?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19975

--- Comment #4 from Chris Wilson <cwilso@gmail.com> ---
> But I doubt it's less expensive to fire a lot of events instead of
> batching them into one.

Of course not!  But I do note that this pattern will force every onmessage
handler to be a loop:

for (var i=0; i<e.MIDIMessages.length; i++)
  processMIDIMessageData( MIDIMessages[i].data );

when on at least some systems (Windows), you'll only ever receive (and thus,
dispatch to the Web MIDI API) one message at a time.  In fact, it wouldn't
surprise me to see some code end up skipping that loop and dereferencing [0],
even though it's wrong, because it will work (on Windows at least).

Additionally, in OSX and USB-MIDI implementations, we've set it up so the data
stream should be deconstructed into MIDI Messages, which means they'll have to
copy the data into a different structure anyway.

In short: I agree with you, it's at best a wash in terms of performance (to not
pass multiple messages on a single call), and at worst, it's slightly worse. 
Depends on your implementation, of course, and how fast your event firing is,
but my understanding is that event firing itself is quite fast, and the
performance issues come in on forcing relayouts in event handlers (or having to
cross thread boundaries repeatedly, which shouldn't be the issue here).

However, I do think the pattern simplifies quite a bit for the MIDI web
developer, which is why I brought it up at all.  The less we have in the v1
API, the easier it is to pick up and understand.

> Anyway, if you have cases where the current model would perform worse than
> the one you suggested, please let me know. Actually the model you suggested
> was also on my mind when I stripped down the MIDIMessage interface to just
> data and timestamp, but I thought the current model gives more breathing
> room for potential optimizations.

We could always, of course, add a more structured "onMessages" that takes
batches later.

> This discussion actually reminds me... We should give some thought to giving
> the MIDIAccess interface to a Web Worker. If outside the main thread none of
> my concerns would be pressing enough to justify having the behavior a bit
> more complex.

I don't actually see a lot of problem with doing that, actually.  I'm not sure
I'd want to sign up for it quite yet, as I'd like to get an initial
implementation or two first, but logistically I'm not overly worried.  I would
want us to map out scenarios for this, however, as I'm not sure you have access
to all the other APIs you might want to make that interesting inside a worker. 
(I.e.: sure, you could get a MIDI message in a worker.  Now what do you want to
do with it?)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 26 November 2012 23:41:24 UTC