Add rerender option for HoloViews pane #1021
Conversation
philippjfr
force-pushed
the
hv_rerender
branch
from
8137ec6 to
5f5616f
Compare
Codecov Report
@@ Coverage Diff @@
## master #1021 +/- ##
==========================================
- Coverage 86% 85.95% -0.05%
==========================================
Files 105 105
Lines 11893 11909 +16
==========================================
+ Hits 10228 10236 +8
- Misses 1665 1673 +8
Continue to review full report at Codecov.
|
|
You will have to better explain what this option does, yet installing the new version from master and using this new rerender option only makes things worse - moving sliders seem not to work at all now at least in one case - I will run a few more tests to make sure, yet if there is any difference than before, it is only worse. |
|
It will almost certainly be slower and result in much larger files but I've not encountered a situation where it doesn't work. |
|
Just to explain both the issues you are having with HoloViews and what this workaround is meant to achieve. Embedding in Panel (and previously the HoloMap support in HoloViews) work by collecting all the widgets in an app that have a discrete set of values and then taking their cross product to come up with the state space. The embedding code then iterates over that state space and records the events that are generated as each change is applied. This works well for simple cases but can exhibit issues with more complex cases when combined with HoloViews. Specifically HoloViews tries to compute the minimal set of events to go from one state to the next. Imagine you have states The correct solution would be to ensure that during embedding HoloViews always includes all the events necessary to fully restore the state. An alternative solution would be to find a path through the state space that applies all the events to get to that state consecutively. Both are pretty difficult problems, particularly while also still minimizing the size of the resulting data. This PR is a total hammer to solve this problem, instead of saying "let's try to compute a minimal diff between A and B" it says, let's just embed the entire plot for each state change. This will result in much bigger file sizes and trigger a full rerender of the plot but it also guarantees all the state changes are recorded in full. |
|
This is a very good explanation, thank you. Yet I have a few questions.
Does state A represent a certain value in Widget 1 or does it represent a
set of values in all widgets?
If a state represents a combination of widget values, then have you
considered creating a null state that you always pass through that resets
everything before moving to the desired end state? This may reduce the
combination numbers - yet again, this is only if I understand the term
state correctly.
However, the problem I am experiencing may be holoviews related or both
holoviews and panel related.
The bottom line is that I can not generate using the newer versions a plot
that works like [this one](
https://jacob-barhak.github.io/PosterIMAG2019Resources/PopulationPlotActive.html
)
Somehow changing combo boxes / sliders fail to do one of the following:
- update the plot image
- update the title properly
- update the axes
And there may be multiple issues here.
Your approach of embedding all states seems nice, since I do not care about
file size, yet this approach does not work for me - the plot just does not
change anything.
Any working solution is welcome, and I am happy to invest time and help
resolve it if you point out the relevant files and I can comprehend them.
I can start by creating a simple reproducible example it you think it will
help.
…On Tue, Jan 28, 2020 at 8:56 AM Philipp Rudiger ***@***.***> wrote:
Just to explain both the issues you are having with HoloViews and what
this workaround is meant to achieve. Embedding in Panel (and previously the
HoloMap support in HoloViews) work by collecting all the widgets in an app
that have a discrete set of values and then taking their cross product to
come up with the state space. The embedding code then iterates over that
state space and records the events that are generated as each change is
applied. This works well for simple cases but *can* exhibit issues with
more complex cases when combined with HoloViews. Specifically HoloViews
tries to compute the minimal set of events to go from one state to the
next. Imagine you have states A, B and C, the embedding code will go from
A->B and record the events, and then go from B->C and record the events,
however since it's computing minimal diffs the transition from C->B may
not include all the events to fully restore the view to the original state
A, because it has only recorded the diff to go from A->B and A and B may
be more similar than C and A. This problem is particularly acute when we
change column labels.
The correct solution would be to ensure that during embedding HoloViews
always includes all the events necessary to fully restore the state. This
is a very difficult problem however, particularly while also still
minimizing the size of the resulting data. This PR is a total hammer to
solve this problem, instead of saying "let's try to compute a minimal diff
between A and B" it says, let's just embed the entire plot for each state
change. This will result in much bigger file sizes and trigger a full
rerender of the plot but it also guarantees all the state changes are
recorded in full.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1021?email_source=notifications&email_token=AAPE427NIHIGX6ZGLC3LYYDRABBRTA5CNFSM4KML7IFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKDS5CY#issuecomment-579284619>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAPE425LBIVUVCM3OMI5VK3RABBRTANCNFSM4KML7IFA>
.
|
It represents a set of values across all widgets.
This may be a very good idea, can't say offhand if it'll work but it's definitely worth investigating
Do you have a smaller example I could try? |
|
If I understand you correctly now, it seems that your Render solution is
probably similar to what I meant by passing through a null state -
eventually it ends up as code replicated as many times as you have states.
I will send you a test example that will show some of the problems by
tomorrow. - I need to cut down the code to reach a small enough example and
it will take some time. Until then many thanks for trying to resolve it
quickly.
…On Tue, Jan 28, 2020 at 10:25 AM Philipp Rudiger ***@***.***> wrote:
Does state A represent a certain value in Widget 1 or does it represent a
set of values in all widgets?
It represents a set of values across all widgets.
If a state represents a combination of widget values, then have you
considered creating a null state that you always pass through that resets
everything before moving to the desired end state? This may reduce the
combination numbers - yet again, this is only if I understand the term
state correctly.
This may be a very good idea, can't say offhand if it'll work but it's
definitely worth investigating
Your approach of embedding all states seems nice, since I do not care about
file size, yet this approach does not work for me - the plot just does not
change anything.
Do you have a smaller example I could try?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1021?email_source=notifications&email_token=AAPE424ZTDSTERCAD4PSGCTRABMBLA5CNFSM4KML7IFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKD7CZA#issuecomment-579334500>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAPE426ANJ7QAUGOSU5F7U3RABMBLANCNFSM4KML7IFA>
.
|
It's similar but in fact a null state may be better overall. Instead of embedding a new plot each time the null state could iterate over all the plots and reset all properties to their defaults. So the basic layout and structure of plots stays the same but everything else about them is reset. |
|
And also, the number of transitions should be reduced by square root, if I
understand this correctly.
If one has N combined states, then there are O(N^2) number of transitions
among those states if I understood the current implementation correctly.
If one uses a null state then there are O(N) transitions between states.
If I am correct, this may be a partial reason for the huge static files. So
adding a Null state, will probably reduce the file.size as well.
I do hope that you have support in double buffering to avoid flickering
graphics - yet I may misunderstand something, so let us do it properly
with some example that currently does not work and make it work. I hope I
can provide one by tomorrow.
…On Tue, Jan 28, 2020 at 11:16 AM Philipp Rudiger ***@***.***> wrote:
If I understand you correctly now, it seems that your Render solution is
probably similar to what I meant by passing through a null state
It's similar but in fact a null state may be better overall. Instead of
embedding a new plot each time the null state could iterate over all the
plots and reset all properties to their defaults. So the basic layout and
structure of plots stays the same but everything else about them is reset.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1021?email_source=notifications&email_token=AAPE425DHKSKMVT7RPJJBFLRABR7LA5CNFSM4KML7IFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKEE7VY#issuecomment-579358679>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAPE4243HVL5AAKMLEQT6HDRABR7LANCNFSM4KML7IFA>
.
|
@Jacob-Barhak Want to try this out, basically just do this with your hv objects: