[Octave-bug-tracker] [bug #53005] Variable editor: slow performance with large arrays

[Dan Sebald]

Follow-up Comment #5, bug #53005 (project octave):

"But then we get the full value back so we update everything on the next
display update...Even so, the variable editor should only have to update the
elements that are displayed, not all elements. That is almost sure to be less
than the full 1,000,000 elements for a 1000x1000 array."

Exactly.  What is currently visible on the screen in the table is only a small
subset of the overall matrix, so when some internal processing is done, the
GUI only needs to retrieve a small subset to display or re-display.  However,
there are a couple complicating factors.  First, I notice that the table
update is a complete restructuring of the layout.  That is, when I expand or
contract the column spacing in the variable editor table, that whole layout is
shrunk back small after some processing initiated from the command-line tab. 
In some sense, that is kind of annoying for the user.  It might be better to
try maintaining the same structure and just update the contents of individual
cells.  Second, the matrix could be made smaller (bigger) with the processing,
e.g., going from 10x10 to 5x5 in which case some cells are going to be lost
(added).  If that cell layout remains constant, we at least know what the
maximum number of columns/rows and we then have a valid range.

So, yeah, one approach is to fill in the whole data model and let the GUI
framework deal with things, but I think the application dictates that can't be
done when there is this background process that could change any contents of
the table.  If there were some callback or listener (not going to happen
because too cumbersome) for which the background process knew what elements to
update in the GUI data model, that would be one solution.  But I think the
only option is for the GUI to be programmed to only display a subset of data
in the table.  It complicates the programming, but not too bad.

Making the cell widths and heights static (as opposed to readjusting with
every data update) could help in that programming.  However, for auto-fit (as
I understand it) one might need a strategy of retrieving data that, say,
starts in the upper-left corner and keeps growing the matrix until all visible
space is used up:

x(15,20)

x(16,20) x(16,21) x(15,21)

x(17,20) x(17,21) x(17,22) x(16, 22) x(15,22)

etc.

if you follow what I'm getting at.

"Currently we don't have a way to mark a variable (or an element of a
variable) as modified and I'm not sure we want the overhead of doing that just
in case it might be open in a GUI variable editor tab."

Yes, that is what I meant above by "not going to happen"...way too cumbersome
and disrupts the concept that the GUI shouldn't be too intertwined with the
core.  But I don't know what you have in mind for "open in the GUI variable
tab".  Are you thinking that a background process could be running while the
person is attempting to edit the variable in the V.E.?  I don't know if that's
a good idea.  What might be best is that when a GUI command line issues a
command to the core the GUI greys out all the variable editor tables.  The
user can't initiate something in the command-line tab if they are editing in
V.E., so I don't think that's a problem.  Then when the background core
process is complete, turn off the grey background in the V.E. and update the
contents.  If the user wants to monitor what's happening in the V.E., s/he
will have to introduce a "pause(0)" in their programming loop somewhere.  The
variable editor might flash from grey to white momentarily, but that would be
a cue to the person watching the screen that the variable contents possibly
changed.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?53005>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/