Performance issues when not connected to an mhub bus

[rikkertkoppes]

When the displaySystem is not connected to a websocket mhub bus, it still periodically tries to make a connection and fails. This is designed to make the system more robust to network glitches by automatically reconnecting.

However, while doing the websocket request, up until it times out, the application is not responsive to user input. You can verify this by opening up the network tab in the developer toolbar. Every time a request is pending, the application is unresponsive

[poelstra]

That's strange... I just tried to do a new WebSocket("ws://some_ip_not_on_my_network") in the JS console of Chrome, and it immediately returns (i.e. it's non-blocking, as expected), even doing a lot of them 'in parallel'.

Doing some googling also doesn't seem to give hits, and I suppose many people would have suffered from this otherwise. Only thing I found so far is http://stackoverflow.com/questions/17219963/apparent-blocking-behaviour-in-javascript-websocket-on-mobile-safari but I don't think you're on Mobile Safari?

It would be interesting to add some console.log statements after the creation of the socket to see if it indeed blocks the event loop, because I highly doubt that...

[kmeesters]

Was this with of the compiled exe @rikkertkoppes ? B/c the first versions were compiled with the trial version of EncloseJS which limits the network connections. Just checking.

[rikkertkoppes]

This is in the live version as well. Some steps to reproduce:

• open displaySystem in chrome
• open dev tools (F12), network tab, select ws tab to show websocket requests
• open the control window (press 'c')
• start hitting the lowThird "toggle" button regularly

Notice that the command does not respond when a websocket request is pending.

Alternatively, by entering displaySystem.modules.lowThird.toggle() repeatedly in the console, the command does work.

So it has something to do with the control window and the command being sent across windows. I will investigate a bit further.

[rikkertkoppes]

Found it

The problem is that when connected to websocket, the command is sent over websocket, instead of directly via js. The idea is that the application receives its own message again via websocket and reacts accordingly. Otherwise, the message would be handled twice, once directly via js, and again when the ws message comes back.

The problem here is that to decide on this, it looked at the presence of a ws instance in the system, not at the connectivity. While connecting, the instance is already there, but it is not connected. Relevant code is here and here

Will create a PR for it