Switches to a update-graphics-on-poll style model where there is a single update loop that makes a couple presumptions:
a main data feed (OHLCV) is normally the source for downstream calculations conducted by the fsp engine
the source data feed is updated at the fastest rate and thus graphics update throttling can be oriented around that arrival rate
down stream fsp computations can be run in parallel and pushed to shared mem but do not need to trigger their own graphics display update loop tasks since the outputs can simply be read from shm and displayed when the source data feeds are updated
this avoids necessary trio task switches and instead attempts to read and display as much graphical changes as possible per source data event arrival
You'll note inside the fsp engire the streams are now disabled by default and consumer actors will need to pass attach_stream=True to enable when wishing to pull per-tick data over IPC.
Oh this also adds back in the rsi fsp for now which is good for peeps to test to make sure vlm and it together aren't introducing any new latency. By default once all the history from #231 is landed we will likely not enable rsi by default.
More factored history from #231.
Switches to a update-graphics-on-poll style model where there is a single update loop that makes a couple presumptions:
triotask switches and instead attempts to read and display as much graphical changes as possible per source data event arrivalYou'll note inside the fsp engire the streams are now disabled by default and consumer actors will need to pass
attach_stream=Trueto enable when wishing to pull per-tick data over IPC.Oh this also adds back in the
rsifsp for now which is good for peeps to test to make surevlmand it together aren't introducing any new latency. By default once all the history from #231 is landed we will likely not enablersiby default.