Multi symbol input (support) #449
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Initial support for real-time multi-symbol overlay charts using an
aggregate feed delivered by `Feed.open_multi_stream()`.
The setup steps for constructing the overlayed plot items is still very
very rough and will likely provide incentive for better refactoring high
level "charting APIs". For each fqsn passed into `display_symbol_data()`
we now synchronously,
- create a single call to `LinkedSplits.plot_ohlc_main() -> `ChartPlotWidget`
where we cache the chart in scope and for all other "sibling" fqsns
we,
- make a call to `ChartPlotWidget.overlay_plotitem()` -> `PlotItem`, hide its axes,
make another call with this plotitem input to
`ChartPlotWidget.draw_curve()`, set a sym-specific view box auto-yrange maxmin callback,
register the plotitem in a global `pis: dict[str, list[pgo.PlotItem, pgo.PlotItem]] = {}`
Once all plots have been created we then asynchronously for each symbol,
- maybe create a volume chart and register it in a similar task-global
table: `vlms: dict[str, ChartPlotWidget] = {}`
- start fsp displays for each symbol
Then common entrypoints are entered once for all symbols:
- a single `graphics_update_loop()` loop-task is started wherein
real-time graphics update components for each symbol are created,
* `L1Labels`
* y-axis last clearing price stickies
* `maxmin()` auto-ranger
* `DisplayState` (stored in a table `dss: dict[str, DisplayState] = {}`)
* an `increment_history_view()` task
and a single call to `Feed.open_multi_stream()` is used to create
a symbol-multiplexed quote stream which drives a single loop over all
symbols wherein for each quote the appropriate components are looked
up and passed to `graphics_update_cycle()`.
- a single call to `open_order_mode()` is made with the first symbol
provided as input, though eventually we want to support passing in the
entire list.
Further internal implementation details:
- special tweaks to the `pg.LinearRegionItem` setup wherein the region
is added with a zero opacity and *after* all plotitem overlays to
avoid and issue where overlays weren't being shown within the region
area in the history chart.
- all symbol-specific graphics oriented update calls are adjusted to
pass in the fqsn:
* `update_fsp_chart()`
* `ChartView._set_yrange()`
* ChartPlotWidget.update_graphics_from_flow()`
- avoid a double increment on sample step updates by not calling the
increment on any vlm chart since it seems the vlm-ohlc chart linking
already takes care of this now?
- use global counters for the last epoch time step to avoid incrementing
all views more then once per new time step given underlying shm array
buffers may be on different array-index values from one another.
Factor out the chart widget creation since it's only executed once during rendering of the first feed/flow whilst keeping plotitem overlay creation inside the (flume oriented) init loop. Only create one vlm and FSP chart/chain for now until we figure out if we want FSPs overlayed by default or selected based on the "front" symbol in use. Add a default color-palette set using shades of gray when plotting overlays. Presume that the display loop's quote throttle rate should be uniformly distributed over all input symbol-feeds for now. Restore feed pausing on mouse interaction.
Move to expect and process new by-tick-event frames where the display loop can now just iterate the most recent tick events by type instead of the entire tick history sequence - thus we reduce iterations inside the update loop. Also, go back to use using the detected display's refresh rate (minus 6) as the default feed requested throttle rate since we can now handle much more bursty-ness in display updates thanks to the new framing format B)
Since higher level charting and fsp management need access to the new `Flume` indexing apis this adjusts some func sigs to pass through (and/or create) flume instances: - `LinkedSplits.add_plot()` and dependents. - `ChartPlotWidget.draw_curve()` and deps, and it now returns a `Flow`. - `.ui._fsp.open_fsp_admin()` and `FspAdmin.open_fsp_ui()` related methods => now we wrap the destination fsp shm in a flume on the admin side and is returned from `.start_engine_method()`. Drop a bunch of (unused) chart widget methods including some already moved to flume methods: `.get_index()`, `.in_view()`, `.last_bar_in_view()`, `.is_valid_index()`.
goodboy
added
feature-request
goodboy
force-pushed
the
multi_symbol_input
branch
from
38c6680 to
07ab853
Compare
guilledk
approved these changes
Feb 5, 2023
77 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Again in support of the final product landing in #420...
This is the initial implementation of multiple symbol input support via the
piker chart <symbol> <symbol> ... <symbol>cli and thus first draft support for multi-feed overlays on a single chart.There is much much much more refinement and fixes coming in the patches leading up to #420 but this gets a more easily reviewable chunk of UI code changes up and a baseline working changeset for overlays onto master.
I won't go into too too much detail but more or less the shortcoming that are improved on later (and will land in future PRs leading to #420) vs. what exists in this version, include:
samplerddaemon sample step updates nor the (RHS) "latest datums" alignment.