Mxmn from m4 #342
Mxmn from m4 #342
Conversation
goodboy
added
viz
graphics
| y_out[bincount, 3] = y | ||
| mx = max(mx, ymx) |
There was a problem hiding this comment.
Yeah so just to point to the crux of it all, there's really no point in not capturing these summary max/min values during each downsample cycle and this is now what we take an use in place of "manual" y-range sorting on the source data when possible.
| chart.increment_view(steps=i_diff) | ||
| # chart.increment_view(steps=i_diff + round(append_diff - uppx)) |
There was a problem hiding this comment.
left this is in because to me the logic makes sense but for whatever reason it doesn't seem to actually be correct based on testing.
Ideally we can get to where there's never an error margin on shifts when optimizing for uppx scaling.
piker/ui/_flows.py
Outdated
| @@ -416,6 +417,10 @@ def maxmin( | |||
| if not slice_view.size: | |||
| mxmn = None | |||
|
|
|||
| elif self.yrange: | |||
There was a problem hiding this comment.
the bit where we choose to use the m4 yrange output if set instead of the normal "manual" sorting calls from prior.
piker/ui/_fsp.py
Outdated
| @@ -776,12 +781,16 @@ def chart_curves( | |||
|
|
|||
| ) -> None: | |||
| for name in names: | |||
|
|
|||
| render = False | |||
There was a problem hiding this comment.
ahh this can be dropped..
Add `ChartPlotWidget._on_screen: bool` which allows detecting for the first state where there is y-range-able flow data loaded and able to be drawn. Check for this flag to be set in `.maxmin()` such that until the historical data is loaded `.default_view()` will be called to ensure that a blank view is never shown: race with the UI starting versus the data layer loading flow graphics can have this outcome.
| f"{flow_key} no mxmn for bars_range => {key} !?" | ||
| ) | ||
| res = 0, 0 | ||
| if not self._on_screen: |
There was a problem hiding this comment.
a hitch to avoid blank views on first datums load..
probably should do something more elegant for this eventually?
DraftWorking POC for an idea I had while pondering #325.The idea is simple: pull total input yrange max and min from the m4 output since it's already computing the values per pixel window and we just need to do one more max min each step and then return the summary values with the output.
MAIN THINGS TO TEST:
--profile 10to thechartcmd and see if you notice any further difference and/or worse numbers from the actual profiler outputNotes:
right now this seems to be most effective on long term crypto (1m) charts and slower (read not as fast) on 1s feeds (due to the large zeroed arrays allocated for trade rates / dark vlm?)now fixed via c620517 which means even zero-ed series are cached correctly and we get the same during-downsample-mxmn speedup effects 😎numbaor a streaming algo (like demire see Faster y-range sorting #325) would do better for zoomed in / source data graphics in view cases..maxmin()callback flow i still find super confusing, mostly because we have fsps on subcharts which each have flows but which also are somewhat needlessly callingChartPlotWidget.maxmin()for each overlayed flow in aPlotItemChartView._maxmin(),._set_yrange(),Flow.maxmin()orchestration to be more "top level triggered" by whatever view is in use and then not have Qt signal callbacks firing all over the place? needs more thought and definitely a rework to make it more understandable (unfortunately this is growing pains of figuring out how to make Qt's signals wackiness fit with our async engine..)._set_yrange()callbacks mess #343