make the viewer more responsive when selecting/first showing a big array #93
Comments
|
Making viewer (editor) more responsive is not the purpose of implementing a "Data Buffer" as suggested in #33 ? |
|
The buffer for the visible data is indeed a part of the picture. But here, before we visualize anything we work on the whole array to compute the min and max values, which for largish arrays is too slow. And I am unsure computing the min/max only on the current buffer is a good enough solution. Having a global min/max that is at first comput 8000 ed on the buffer and "enlarged" as necessary when we get more data might be a good solution AND/OR do like we do for ndigits/scientific: compute it on a sample (pick a few hundred values from all over the array to minimize bias for "increasing" arrays) |
|
FWIW, here the slowdown I speak about is the time it takes between selecting the array in the list and the data being displayed. This issue is not about scrolling speed like #38. |
gdementen
added a commit
to gdementen/larray-editor
that referenced
this issue
Nov 10, 2017
… (issue larray-project#93) (so that we compute & redraw the new visible data only once)
gdementen
added a commit
to gdementen/larray-editor
that referenced
this issue
Nov 10, 2017
gdementen
added a commit
to gdementen/larray-editor
that referenced
this issue
Nov 10, 2017
…ox for axes >= 10000 elements (issue larray-project#93)
gdementen
added a commit
to gdementen/larray-editor
that referenced
this issue
Nov 10, 2017
…es per change (issue larray-project#93)
gdementen
added a commit
to gdementen/larray-editor
that referenced
this issue
Nov 10, 2017
…t#93) * one of the goal was to make switching from one array to another as fast as possible by cutting down on the repeated calls (to various set_data and datamodel.reset()) * tightened what is accepted by each internal class. There is only one expected type for the data. External facing classes should still accept the same objects. * all internal classes which "hold" data are created without any data in __init__ but require a set_data before they can function. * data_model.reset_minmax needs to be called explicitly. * data_model.reset() needs to be called explicitly when "everything is done"
gdementen
added a commit
to gdementen/larray-editor
that referenced
this issue
Nov 10, 2017
on the whole array but on a sample (fixes larray-project#93) This means we can miss the actual min/max of the displayed part, so it complexifies the code. Most of this awful code will go away after : * we invert how changes work (store old values instead of new values) * we get decent buffering (in that case the min/max should only be updated when "moving" the buffer.
gdementen
added a commit
to gdementen/larray-editor
that referenced
this issue
Nov 21, 2017
…t#93) * one of the goal was to make switching from one array to another as fast as possible by cutting down on the repeated calls (to various set_data and datamodel.reset()) * tightened what is accepted by each internal class. There is only one expected type for the data. External facing classes should still accept the same objects. * all internal classes which "hold" data are created without any data in __init__ but require a set_data before they can function. * data_model.reset_minmax needs to be called explicitly. * data_model.reset() needs to be called explicitly when "everything is done"
gdementen
added a commit
to gdementen/larray-editor
that referenced
this issue
Nov 21, 2017
on the whole array but on a sample (fixes larray-project#93) This means we can miss the actual min/max of the displayed part, so it complexifies the code. Most of this awful code will go away after : * we invert how changes work (store old values instead of new values) * we get decent buffering (in that case the min/max should only be updated when "moving" the buffer.
gdementen
added a commit
that referenced
8000
this issue
Nov 21, 2017
… (issue #93) (so that we compute & redraw the new visible data only once)
gdementen
added a commit
that referenced
this issue
Nov 21, 2017
gdementen
added a commit
that referenced
this issue
Nov 21, 2017
…ox for axes >= 10000 elements (issue #93)
gdementen
added a commit
that referenced
this issue
Nov 21, 2017
* one of the goal was to make switching from one array to another as fast as possible by cutting down on the repeated calls (to various set_data and datamodel.reset()) * tightened what is accepted by each internal class. There is only one expected type for the data. External facing classes should still accept the same objects. * all internal classes which "hold" data are created without any data in __init__ but require a set_data before they can function. * data_model.reset_minmax needs to be called explicitly. * data_model.reset() needs to be called explicitly when "everything is done"
gdementen
added a commit
to gdementen/larray-editor
that referenced
this issue
Sep 3, 2018
… (issue larray-project#93) (so that we compute & redraw the new visible data only once)
gdementen
added a commit
to gdementen/larray-editor
that referenced
this issue
Sep 3, 2018
gdementen
added a commit
to gdementen/larray-editor
that referenced
this issue
Sep 3, 2018
…ox for axes >= 10000 elements (issue larray-project#93)
gdementen
added a commit
to gdementen/larray-editor
that referenced
this issue
Sep 3, 2018
…es per change (issue larray-project#93)
gdementen
added a commit
to gdementen/larray-editor
that referenced
this issue
Sep 3, 2018
…t#93) * one of the goal was to make switching from one array to another as fast as possible by cutting down on the repeated calls (to various set_data and datamodel.reset()) * tightened what is accepted by each internal class. There is only one expected type for the data. External facing classes should still accept the same objects. * all internal classes which "hold" data are created without any data in __init__ but require a set_data before they can function. * data_model.reset_minmax needs to be called explicitly. * data_model.reset() needs to be called explicitly when "everything is done"
gdementen
added a commit
to gdementen/larray-editor
that referenced
this issue
Sep 3, 2018
on the whole array but on a sample (fixes larray-project#93) This means we can miss the actual min/max of the displayed part, so it complexifies the code. Most of this awful code will go away after : * we invert how changes work (store old values instead of new values) * we get decent buffering (in that case the min/max should only be updated when "moving" the buffer.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently it slows down to a crawl when working with big arrays.
The vmin/vmax computation could be the culprit. Being fast is more important than having perfect colors, so IF that is indeed the cause of the slowdown, we should use a sample, like for computing ndigits. But then the color code needs to be adapted to cope with having colorval > vmax OR, preferably updating vmin/vmax as we go, when loading more data.
The text was updated successfully, but these errors were encountered: