USB subsystem improvements for Screen updates

[harryhaaren]

For screen updates, copying the data is a good way to cache-trash (particularly on low-powered devices). To avoid unnecessary copies, the USB bulk write system should be turned "inside out".

End state should be something as follows:

• Application registers a "screen update" callback
  -- Called at the interval as best supported by the driver
  -- Optionally we could add a "target fps" to run the redraw-timer at
• When a redraw is scheduled:
  -- The driver callback for screen-draw is called
  -- The driver requests the USB buffer of based on its screens' capabilities + features below
  -- The USB core provides said buffer
  -- The driver "skips" into the buffer some amount - the size of a few canary bytes, any prepended-header as required by the device. The header canary and buffer-header are initialized, tail canary (post app-drawn data) is initialized
  -- This "skipped-in" pointer is provided to the application screen redraw callback, and the app draws
  -- Control returns to the driver, which performs a sanity check on the canaries and the header bytes
  -- If checks pass, the driver submits the USB request to the Ctlra USB core infrastructure.

This approach allows flexibility - a simple malloc() could be used to provide the USB buffer, or smarter approaches could be attempted. The app draws directly to the buffer that will be submitted to the USB system. This may be a down-side for partial-updates... the driver could "hide" a layer of buffering here easily - allowing applications to only do partial updates.

Todo:

• Think about partial updates, in regards to double buffering
• Think about how to have this work for virtual devices - rescale + draw the buffer?

[Be-ing]

What happens if the application does not render fast enough?

[harryhaaren]

Good question.

Ultimately the "rendering" is probably going into the Mixxx-Ctlra thread. This thread will also perform USB I/O and some other tasks (like low-latency things: reading button-presses from the device). The simple way to explain this is that the callback will be invoked on the application by that thread, and the UI drawing code will be running there. If the code is slow, it will have an impact on available cycles for that thread.

It is relatively easy to measure time-elapsed in the drawing code - this could be provided to developers/users for debugging purposes. If the drawing really becomes an issue, then we can discuss how to fix it. I'm usually quite driven by real-experience or at least data - until then, I won't worry about it.

Another point of view, is that the callback-to-redraw mechanism isn't the failure if the app-redraw is too slow. If we really do need to get GLSL support and things like that implemented, there are methods to do that - but I'm hesitant to "jump" to conclusions about performance, when we don't even any any POC yet.

[Be-ing]

If we really do need to get GLSL support and things like that implemented, there are methods to do that - but I'm hesitant to "jump" to conclusions about performance, when we don't even any any POC yet.

Wouldn't it be up to the application to use GLSL or whatever else for the rendering? Ctlra doesn't have anything to do with the implementation of that, does it?

[harryhaaren]

Not really - but what if Ctlra had the smarts to provide either A) a Cairo backend, or B) a GL context to just run the shaders in? Just a thought - realistically it would be in a "helper" library that is optional - the Ctlra interface should be raw bytes for each device I think - abstracting it more than that is probably scope-creep.

[Be-ing]

Yeah, that would definitely be scope creep. The choice of how to render those raw bytes should be left with the application developer.

[harryhaaren]

Point taken - thanks for the input!