Move to DOM rendering (CEF)

[vreelb]

I've been thinking about the move over to CEF, and while we're at it it would probably be good to make things a bit more modular (given how much of a pain it was to add softball).

Here's the rough outline I had in mind:

Each style would have to take into account support for different games (as their display HTML would differ some), although we could have some reasonable defaults. I don't want to paint us into the corner of slantRectangle forever (or whatever its successor may be).

More important though is the ability to add new sports easily. I'd like it to be as simple as dropping in a folder with the required details (game logic, control html/css, display html).

[vreelb]

After a discussion with @braune13 we were thinking that Angular may be the best option moving forward given what is needed (particularly on the front-end). While I don't want to be the kind of person to throw everything away and do a complete rewrite, I do think that we're going to need to change enough that it might be best to move away from Ruby and to a Node/Angular solution entirely. Not only to avoid a Frankenstein application of the old and new being patched together, but also because fewer and fewer people are familiar enough with Ruby to make this easy to maintain moving forward (and admittedly I would rather become more familiar with the highly sought-after Angular). Obviously this would be best if it could be done in stages, but I would like to move over completely in the long-term.

Thoughts? I'm trying to have the discussion here because this seems more appropriate than Slack (and doesn't eat messages).

[vreelb]

npm does have a serialport library so the sync files should theoretically just need to be transposed into javascript.

[asquared]

I wouldn't oppose a change of language, nor a complete rewrite... There is code in here that was a hack six years ago and has been there ever since. Node would be a good choice, although the serial port stuff will need to be converted from threads to async IO. This shouldn't be a big problem.

…

-Andrew

On May 18, 2017 14:42, "Ben Vreeland" ***@***.***> wrote: npm does have a serialport library so the sync files should theoretically just need to be transposed into javascript. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#57 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAF3r4smBo2cFg96H2F_bGk7FIARVdmJks5r7JEhgaJpZM4NTOwv> .

[kench]

DOM-based keying is the de facto method of rendering graphics for live streams on YouTube and Twitch. Broadcasters use a variety of different "overlays" by adding a "browser source" (typically powered by CEF) in their streaming program of choice and specifying the URL of the page they wish to render.

Keying is accomplished using the RGBA CSS property or traditional "green screen" keying using the color green.

Events (follows, tips, and other actions) as well as broadcaster initiated commands are "pushed" from a webserver directly to the JavaScript running inside the CEF process.

I have taken a look at how the two most popular software-as-a-service solutions (Streamlabs and Muxy) for DOM-based graphics work under the hood. Streamlabs uses an unknown notification/eventing channel (as in, I haven't figured out from looking at network traces in the inspector), while Muxy uses JSON payloads over WebSockets to push commands to the DOM renderer.

I strongly encourage playing around with Streamlabs (and Muxy, if you have time) and OBS (with the CEF browsersource plugin) to understand the user experience.

https://streamlabs.com/
https://muxy.io/

[kench]

I think there is room for improvement in the area of developing reusable libraries/components/building blocks for "making spiffy looking graphics using a DOM-based renderer where various aspects of its appearance need to be controlled in real-time" - scoreboards and on-screen alerts are two things that fall in this bucket.

The first technical area of improvement is acknowledgement of real-time commands. The lack of traceability when network issues happen is a huge pain that I see when troubleshooting alert packages.

In our case, a DOM-based scoreboard (the Scoreboard) would have a web-facing control component (the Web UI) operated by a dedicated person. In this example, we'll call him Andrew. The DOM-based scoreboard and Web UI communicates with a WebSocket server (the Server), which is responsible for relaying commands between the Scoreboard and the Web UI.

When Andrew wants to add a penalty to the scoreboard, the following should happen (in an async, non-blocking manner).

1. The Web UI sends a message to the Server, prompted by Andrew's user input.
2. The Server sends back a notification to the Web UI acknowledging the message. (Best effort)
3. The Server sends the message to the Scoreboard.
4. The Server sends a notification to the Web UI that the message was sent to the Scoreboard. (Best effort)
5. The Scoreboard sends an acknowledgement that the message was received to the Server, which will relay it to the client. (Best effort)
6. The Scoreboard attempts to perform a graphics update.
7. Scoreboard sends a notification back to the Server that the graphics update succeeded, which is relayed to the Web UI.

I also want to emphasize the important of keeping scoreboard data/state in sync in case the DOM renderer crashes and needs to be restarted, but I need sleep.