Sign up

Pages: 1 2

grid failure

hi,

i need to provide a view into a data matrix, i.e. (mostly square) arrays
of integer values, at least up to 512x512. the values should be
copyable, i don't think i need them editable ATM.

so i don't need a fancy spreadsheet widget (which i would not mind
having though). i tried displaying my data in a
(selectable) Label/Grid/Viewport/ScrolledWindow manner, but it did not
work so well:

  • i can do 104x104 (looks fine just as i want it), but 128x128 crashes
    the program without error message on myWindow.showAll

  • it takes almost 1 second to prepare the grid of labels (104x104)

  • the memory consumption is horrendous, about 5KB per cell (i.e. Label
    in Grid in this case): so even if it would run, a 512x512 matrix would
    take up > 1GB - clearly not acceptable.

so i am wondering if there is a better way?

and if there is a chance gtk.extra http://gtkextra.sourceforge.net/cms/
could be wrapped and distributed with GtkD? it seems to provide a
spreadsheet widget. i have no clue about the copyright stuff though.

thanks,

det

ps: i am on windows, using GtkD-3.3.0, DMD-2.068.2 32bit, gtk3.18.3

Re: grid failure

On 06/15/2016 02:46 PM, captaindet wrote:

hi,

i need to provide a view into a data matrix, i.e. (mostly square) arrays
of integer values, at least up to 512x512. the values should be
copyable, i don't think i need them editable ATM.

so i don't need a fancy spreadsheet widget (which i would not mind
having though). i tried displaying my data in a
(selectable) Label/Grid/Viewport/ScrolledWindow manner, but it did not
work so well:

  • i can do 104x104 (looks fine just as i want it), but 128x128 crashes

the program without error message on myWindow.showAll

  • it takes almost 1 second to prepare the grid of labels (104x104)

  • the memory consumption is horrendous, about 5KB per cell (i.e. Label

in Grid in this case): so even if it would run, a 512x512 matrix would
take up > 1GB - clearly not acceptable.

so i am wondering if there is a better way?

and if there is a chance gtk.extra http://gtkextra.sourceforge.net/cms/
could be wrapped and distributed with GtkD? it seems to provide a
spreadsheet widget. i have no clue about the copyright stuff though.

thanks,

det

ps: i am on windows, using GtkD-3.3.0, DMD-2.068.2 32bit, gtk3.18.3

You probably want a ListView?

An example that also does some custom rendering:
https://github.com/gtkd-developers/GtkD/blob/master/demos/gtkD/DemoMultiCellRenderer/DemoMultiCellRenderer.d

Re: grid failure + TreeView underperformance

(selectable) Label/Grid/Viewport/ScrolledWindow manner, but it did not
work so well:

i should add for completeness that once i made the label selectable,
responsiveness of a 104x104 grid-matrix was bogged down to utter
uselessness.

On 2016-06-17 06:50, Mike Wey wrote:

You probably want a ListView?

An example that also does some custom rendering:
https://github.com/gtkd-developers/GtkD/blob/master/demos/gtkD/DemoMultiCellRenderer/DemoMultiCellRenderer.d

you mean a ListStore/TreeView combination?

well i was hoping i could avoid the extra complexity of a full blown
data/view model. being forced to, i gave it a try now:

  • good news, it does not crash on large data sets, i tried up to 256x256
    matrices alright

  • even better news, memory consumption is very reasonable, much lower
    than for the grid approach

  • however, performance is completely unacceptable. it takes more than 3
    seconds to prepare a 256x256 matrix in ListStore/TreeView and more than
    17 seconds for a 512x512. about 10% of the time goes to filling the
    ListStore, while 90% is taken for building a TreeView from the model.
    also, it hardly makes a difference if in debug or release mode or if the
    GC is disabled during the ListStore/TreeView construction.

  • not that it matters for my current use case but out of curiosity: how
    can the TreeView be configured to not highlight a row? i would want to
    select individual cells, never rows or columns.

so it really seems to be the worst case scenario: i'll have to roll my
own (lightweight) spreadsheet. as in figuring out how many rows/columns
fit in the current widget space, arrange them (probably as grid of
selectable labels), manage my own scrollbars, manually change the data
on display in response to the scroll position...just to display a simple
data matrix. this sucks big time :(

Re: grid failure + TreeView underperformance

On 06/19/2016 02:03 AM, captaindet wrote:

you mean a ListStore/TreeView combination?

yes.

well i was hoping i could avoid the extra complexity of a full blown
data/view model. being forced to, i gave it a try now:

  • good news, it does not crash on large data sets, i tried up to 256x256

matrices alright

  • even better news, memory consumption is very reasonable, much lower

than for the grid approach

  • however, performance is completely unacceptable. it takes more than 3

seconds to prepare a 256x256 matrix in ListStore/TreeView and more than
17 seconds for a 512x512. about 10% of the time goes to filling the
ListStore, while 90% is taken for building a TreeView from the model.
also, it hardly makes a difference if in debug or release mode or if the
GC is disabled during the ListStore/TreeView construction.

  • not that it matters for my current use case but out of curiosity: how

can the TreeView be configured to not highlight a row? i would want to
select individual cells, never rows or columns.

You would have to implement some of the selection logic your self:
http://www.gtkforums.com/viewtopic.php?p=7354

so it really seems to be the worst case scenario: i'll have to roll my
own (lightweight) spreadsheet. as in figuring out how many rows/columns
fit in the current widget space, arrange them (probably as grid of
selectable labels), manage my own scrollbars, manually change the data
on display in response to the scroll position...just to display a simple
data matrix. this sucks big time :(

You might want to look at a custom tree model for that case:
https://github.com/gtkd-developers/GtkD/tree/master/demos/gtkD/DemoCustomList

The demo only implements a simple list stored in an internal array.
But the TreeView only queries the visible rows, so that would hopefully
help with the performance. Additionally the data to be displayed can be
queried from where it is actually stored instead of building a separate
list beforehand.

Re: grid failure + TreeView underperformance

You would have to implement some of the selection logic your self:
http://www.gtkforums.com/viewtopic.php?p=7354

thanks mike. so there is a workaround if i ever get that far with the
TreeView approach.

so it really seems to be the worst case scenario: i'll have to roll my
own (lightweight) spreadsheet. as in figuring out how many rows/columns
fit in the current widget space, arrange them (probably as grid of
selectable labels), manage my own scrollbars, manually change the data
on display in response to the scroll position...just to display a simple
data matrix. this sucks big time :(

You might want to look at a custom tree model for that case:
https://github.com/gtkd-developers/GtkD/tree/master/demos/gtkD/DemoCustomList

The demo only implements a simple list stored in an internal array.
But the TreeView only queries the visible rows, so that would hopefully
help with the performance. Additionally the data to be displayed can be
queried from where it is actually stored instead of building a separate
list beforehand.

interesting, i did not know a CellRendererText can display
numbers/integers directly.

and as you pointed out, tweaking this demo example could allow me to use
my raw data directly as input model for TreeView. this is not the time
sink, but would save some memory.

i don't understand, though, how this example helps to build my own
lightweight spreadsheet. it also uses a ScrolledWindow to reduce the
view on the model to what the current window offers - same as i did in
my testing.

in the meantime i have narrowed down the main problem of TreeView a bit
more. as the following example shows it is the mere creation of columns
that is of glacial speed, even if there is only one row and no data
model involved...
am i doing something fundamentally wrong here?
is there a trick to speed things up?
is this so slow in C/GTK as well?

enum cols = 512;
//  TreeView built: 15 secs, 980 ms
//  TreeView shown + GC collected: 16 secs, 329 ms

void main(string[] args){
     import std.stdio        : writeln;
     import std.datetime     : Duration, StopWatch;
     import std.conv         : to;
     import core.memory      : GC;
     import gtk.Main, gtk.Window, gtk.ScrolledWindow;
     import gtk.TreeView, gtk.TreeSelection;
     import gtk.TreeViewColumn, gtk.CellRendererText;

     Main.init(args);

     StopWatch sw;

     sw.start();
     GC.disable;

     auto tv  = new TreeView();
     tv.setHeadersVisible(false);
     tv.setReorderable(false);
     tv.setShowExpanders(false);
     auto ts = tv.getSelection();
     ts.setMode(SelectionMode.NONE);
     foreach( x; 0..cols){
         auto col = new TreeViewColumn();
         tv.appendColumn(col);
         auto cren = new CellRendererText();
         col.packStart(cren, false );
     }
     writeln( "TV built: ", sw.peek.to!Duration );

     auto scw = new ScrolledWindow;
     scw.add(tv);
     auto win = new Window("listview test");
     win.add(scw);
     win.showAll;
     GC.enable;
     GC.collect;
     sw.stop();
     writeln( "TV shown + GC collected: ", sw.peek.to!Duration );

     win.addOnHide( delegate void(Widget){ Main.quit(); } );

     Main.run;
}

Re: grid failure + TreeView underperformance

On 06/20/2016 04:19 AM, captaindet wrote:

You would have to implement some of the selection logic your self:
http://www.gtkforums.com/viewtopic.php?p=7354

thanks mike. so there is a workaround if i ever get that far with the
TreeView approach.

so it really seems to be the worst case scenario: i'll have to roll my
own (lightweight) spreadsheet. as in figuring out how many rows/columns
fit in the current widget space, arrange them (probably as grid of
selectable labels), manage my own scrollbars, manually change the data
on display in response to the scroll position...just to display a simple
data matrix. this sucks big time :(

You might want to look at a custom tree model for that case:
https://github.com/gtkd-developers/GtkD/tree/master/demos/gtkD/DemoCustomList

The demo only implements a simple list stored in an internal array.
But the TreeView only queries the visible rows, so that would hopefully
help with the performance. Additionally the data to be displayed can be
queried from where it is actually stored instead of building a separate
list beforehand.

interesting, i did not know a CellRendererText can display
numbers/integers directly.

and as you pointed out, tweaking this demo example could allow me to use
my raw data directly as input model for TreeView. this is not the time
sink, but would save some memory.

i don't understand, though, how this example helps to build my own
lightweight spreadsheet. it also uses a ScrolledWindow to reduce the
view on the model to what the current window offers - same as i did in
my testing.

in the meantime i have narrowed down the main problem of TreeView a bit
more. as the following example shows it is the mere creation of columns
that is of glacial speed, even if there is only one row and no data
model involved...
am i doing something fundamentally wrong here?
is there a trick to speed things up?
is this so slow in C/GTK as well?

I would reuse the Renderer, but other than that i don't see anything wrong.

Re: grid failure + TreeView underperformance

I would reuse the Renderer, but other than that i don't see anything wrong.

thanks mike. unfortunately it does not make a difference. even w/o a
renderer at all, just adding empty columns, TreeView still needs 16s to
append 512 columns. this is 32 columns/sec. it takes longer to append a
column than for an ego shooter to render a full HD scene...

i also played with fixed sizes (width, height) to now avail. frustrating
this is.

Re: grid failure + TreeView underperformance

On 06/21/2016 01:21 AM, captaindet wrote:

I would reuse the Renderer, but other than that i don't see anything
wrong.

thanks mike. unfortunately it does not make a difference. even w/o a
renderer at all, just adding empty columns, TreeView still needs 16s to
append 512 columns. this is 32 columns/sec. it takes longer to append a
column than for an ego shooter to render a full HD scene...

i also played with fixed sizes (width, height) to now avail. frustrating
this is.

This seems to be specific to Windows. Running your code on Linux i get this:

TV built: 38 ms
TV shown + GC collected: 138 ms, 598 μs, and 4 hnsecs

512 columns. I'll try it on Windows later this week.

Re: grid failure + TreeView underperformance

On 2016-06-22 08:26, Mike Wey wrote:

This seems to be specific to Windows. Running your code on Linux i get
this:

TV built: 38 ms
TV shown + GC collected: 138 ms, 598 μs, and 4 hnsecs

512 columns. I'll try it on Windows later this week.

wow! with this speed TreeView would be my savior. thanks for looking
into this. FWIW, i have also tested it with antivirus, HIPS, etc
temporarily turned off - no change. the task manager tells me that the
demo program uses 100% of one core/thread for 16 seconds.

also, my first tests with Grid showed a similar, slow behavior (in
addition to the crash for larger number of cells and the overblown
memory consumption).

thanks again, i am looking forward to seeing your windows results.

/det

Re: grid failure + TreeView underperformance

On Wed, 22 Jun 2016 15:02:40 +1200, captaindet wrote:

wow! with this speed TreeView would be my savior. thanks for looking
into this. FWIW, i have also tested it with antivirus, HIPS, etc
temporarily turned off - no change. the task manager tells me that the
demo program uses 100% of one core/thread for 16 seconds.

also, my first tests with Grid showed a similar, slow behavior (in
addition to the crash for larger number of cells and the overblown
memory consumption).

thanks again, i am looking forward to seeing your windows results.

/det

Seems to be fixed in GTK+ 3.20. I'll look into creating a newer installer.

Pages: 1 2