otak / b0xx-viewer-rs Goto Github PK

Need to investigate.

After diagnostics, it turns out we're polling the b0xx controller each ~0-1ms which basically makes no sense as consoles don't poll it higher than 120Hz.

Thus, a full refactor of the serial poll run loop is needed to drastically lower CPU usage.

Making use of the RTS/CTS serial control flow mechanic will be needed for this to work reliably.

• RTS
• Read 18 bytes of data
• CTS
• Wait 8ms
• Repeat

Two ways:

• List of arduino VID/PIDs
• Loosen the name requirement (Arduino* instead of "Arduino Leonardo")

Maybe both

The chromeless launch option cannot be moved by default in Windows, and allowing it would be ideal for any sort of screen capture software or streams that cannot capture multiple distinct windows and overlay them to your specifications (e.g. Discord or other casual streaming settings).

Potentially adding some sort of key combination that would interact with the mouse input, such as Alt + Click or something similar would be ideal.

Admittedly this is not the most common use case, but it would facilitate ease of use in settings outside OBS streaming or similar.

When setting background to a color that you then chroma-key in OBS, the buttons get green outlines.

Seems we have a perf regression on our hands, to investigate

As conrod is unmaintained (PistonDevelopers/conrod#1454) we should move away to another GUI library

Candidates:

1. quadrate - Simple synonym of rectangle
2. fenetre - French for Window, which is usually a...rectangle that allows to see through (view)
3. prism - Well, duh, it's a prism
4. blocky - Rectangle-y and cute, also easy to remember
5. parallelogram - High society rectangle
6. oblong - Rectangle synonym
7. parallelograph - Parallelogram + graph

We sometimes start reading partial buffers over the serial link, problem which also exists on the official Input Viewer. Seems to be some kind of UB related to COM port internal systems.

The procedure to fix this would be to exhaust the initial read buffer at the start of the serial port connection till we find a \n then hand over control to the UI to proceed normally.

CPU usage is through the roof, with visible input lag

Waiting for spec / RE results

We might need an optimization in order to reduce the framerate in those situations instead of trying to render at Vsync

Leaving the viewer alone for a while creates a buffer shift which translates to incorrect button matching.
Probably the same issue with buffer exhaustion on Windows as before

Investigate something like this for button borders

• 2px, rim color defaults to inactive_background_color for the button, make button background = window background
• on pressed, switch button background to active_background_color

This behavior should be enabled with an user-supplied flag