HTML5 client improvements

[totaam]

Following up #69.

Many new chrome features can be found here: https://chromestatus.com/features

Worth a look:

• Custom scheme handlers: the registerProtocolHandler() method: register the html5 client as handler for xpra:// urls. (and xpra+ssl, etc as per more url scheme handling xpra#1894)
• Wake Lock API: maybe prevent suspend when fullscreen? (if that's not the case already)
• deviceMemory expose navigator.deviceMemory to the server? (and avoid using video on low power devices)
• InputEvent handling for input methods?
• Screen.pixelDepth and Screen.colorDepth: enable 10 bpp? Note: The colorDepth and pixelDepth attributes return the same value for compatibility reasons. and Note: Some non-conforming implementations are known to return 32 instead of 24.
• Window.devicePixelRatio (More about devicePixelRatio): HTML5 client on HIDPI screens #13
• Window Placement ie: one window per monitor in shadow mode (#1801)
• WebSocketStream: Provide a WebSocket API that supports backpressure..., see also websocket.bufferedamount: the number of bytes of application data that have been queued using send() but that, as of the last time the event loop reached step 1, had not yet been transmitted to the network
• WebTransport: a mechanism to send many messages as quickly as possibly, possibly out of order, and possibly unreliably from client to server or server to client
• Add a low latency mode for OffscreenCanvas / Add a low latency mode for 2D/3D Canvas contexts / Add lowLatency flag to CanvasRenderingContext2DSettings
• Keyboard Lock: While in fullscreen, this API allows apps to receive keys that are normally handled by the system or the browser like Cmd/Alt-Tab, or Esc. Users can escape keyboard lock (and fullscreen) by holding the Esc key for two seconds.

[totaam]

More on websockets backpressure:

• Chrome Platform Status: WebSocketStream
• Segmented-Audio over Websockets to HTML5: It currently chooses a 1-second fragment size. The reassembly buffer requires a few segments before it starts. The resulting audio latency is 4 to 5 seconds as a result., This lesson was apparent in the application. Without backpressure monitoring, we could not control latency properly.
• Backpressure in Action with Websockets and akka-streams: You, however, need to keep in mind that on OS level, both on the receiver and sender side, you have to deal with TCP buffering. Depending on your OS, this can have a very big effect on when backpressure kicks in.

[totaam]

See also Xpra-org/xpra#2421, Xpra-org/xpra#2471.

[totaam]

New: #5