[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 #5 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> ---
(In reply to comment #4)
> > 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.

Like I said, this may not be true even for Windows, because you might receive
several messages during the main thread being blocked, so these can be stacked
into a single event.

> 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?)

Yeah, it's probably not something we should worry about right now. Although,
even without any interesting APIs you can do stuff like arpeggiating MIDI
messages, which would be more reliable if it's done in a worker.

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

Received on Thursday, 29 November 2012 18:55:52 UTC