UI Performance Issues

[jhnsnc]

(FYI: I'm currently working on a PR for this)

I've taken a closer look at the UI code and I have some ideas on how to improve performance. Here are some of the things I'm considering addressing:

• using setInterval for regular updates instead of the more efficient requestAnimationFrame
• querying the DOM every time an element is mutated instead of caching DOM references
• using jQuery's replaceWith to overwrite element markup rather than mutating the existing element
• scrolling patterns by modifying scrollTop rather than using CSS transforms (scroll seems to cause unnecessary repaints)

Note that I don't have a precise way of measuring the mod player's performance. My current method is measuring general JS performance with Chrome dev tools (though that's not a direct indicator of perceived WebAudio performance). I also have several mods that play very slowly (with a lot of hitching) and so hopefully those will play back smoother as UI performance improves.

[electronoora]

Sounds good. The scrolling pattern visualisation seems to be - at least on iOS Safari - the most CPU intensive part of the UI. Especially when switching over from one pattern to another, the change in visibility within the DOM seems to incur a serious performance hit.

I'm assuming a part of the problem is the fact that a single pattern consists of a huge number of span -elements. Using spans more sparingly and applying them only where colour other than the baseline gray is needed had a visible effect on performance. Still, busy multichannel modules are still quite heavy on the CPU. I don't know if there are better ways to emulate text mode character attributes without bloating up the DOM too much.

Using jQuery id selectors wherever applicable instead of class selectors seems to also improve performance significantly.

Regarding stuttering audio, the XM player code seems to be especially bad in some modules. I'm suspecting that this may not be UI-related, but instead an issue with bugs in the volume ramping and/or interpolation code - namely, some FP operations returning NaN or Inf. I'm assuming this is due to overhead from handling SIMD FP exceptions from the CPU.