|
|
|
|
|
| Re: column width [message #946318 is a reply to message #902647] |
Tue, 16 October 2012 05:31   |
 Jay Norwood
Messages: 112
Registered: July 2009 |
Senior Member |
|
|
I noticed that the virtual nature of the table kind of gets in the way, so I had to leave this paint listener enabled. This works for me,but I wonder whether the calls will scale well. You add it as you add the other OverlayPainters in the examples. I'll take a look at the faq now...
import java.util.HashSet;
import org.eclipse.nebula.widgets.nattable.NatTable;
import org.eclipse.nebula.widgets.nattable.layer.ILayer;
import org.eclipse.nebula.widgets.nattable.painter.IOverlayPainter;
import org.eclipse.nebula.widgets.nattable.resize.command.InitializeAutoResizeColumnsCommand;
import org.eclipse.nebula.widgets.nattable.resize.command.InitializeAutoResizeRowsCommand;
import org.eclipse.nebula.widgets.nattable.util.GCFactory;
import org.eclipse.swt.graphics.GC;
public class ResizeOverlayPainter implements IOverlayPainter {
private NatTable table;
private HashSet<Integer> rowset;
private HashSet<Integer> colset;
ResizeOverlayPainter(NatTable tb){
table = tb;
rowset = new HashSet<Integer>(100);
colset = new HashSet<Integer>(100);
}
@Override
public synchronized void paintOverlay(GC gc, ILayer layer) {
int count = table.getColumnCount();
for (int i=0; i<count; i++) {
if (table.isColumnPositionResizable(i)==false){
continue;
}
int pos = table.getColumnIndexByPosition(i);
if (colset.contains(pos)) continue;
colset.add(pos);
InitializeAutoResizeColumnsCommand columnCommand = new InitializeAutoResizeColumnsCommand(
table, i, table.getConfigRegistry(), new GCFactory(table));
table.doCommand(columnCommand);
}
count = table.getRowCount();
for (int i=0; i<count; i++) {
if (table.isRowPositionResizable(i)==false){
continue;
}
int pos = table.getRowIndexByPosition(i);
if (rowset.contains(pos)) continue;
rowset.add(pos);
InitializeAutoResizeRowsCommand rowCommand = new InitializeAutoResizeRowsCommand(
table, i, table.getConfigRegistry(), new GCFactory(table));
table.doCommand(rowCommand);
}
}
}
|
|
|
|
| Re: column width [message #946893 is a reply to message #946425] |
Tue, 16 October 2012 15:59 |
Jay Norwood
Messages: 112
Registered: July 2009 |
Senior Member |
|
|
ok for using it in the faq. I added your faq example code to the Big_data example and found a couple of problems ...
1. in your example you'd need to change natTable to final.
2. in your example you'd need to remove the override.
Then it builds ok.
The big_data example runs then, but is fairly unresponsive. I believe the time is being spent in getPreferredColumnWidth, which doesn't scale. It appears to look at all rows during execution of InitializeAutoResizeColumnsCommand, rather than just at the the viewed rows. A version of these which only considered the viewed cells might be more responsive. It currently takes on the order of 30 secs per column to resize.
The getPreferedRowHeights is doing the same, but the Big_data example only has 500 rows, and so its problems don't show up in my current test. But if I change the test to 10K rows and 10K columns I see even worse responsiveness due to getPreferedRowHeights calculation relative to getPreferredColumnWidth. So probably should have a more responsive version of both of these for large virtual tables, limiting to just the viewed columns and rows for the resize preferred heights and widths.
private static int getPreferredColumnWidth(ILayer layer, int columnPosition, IConfigRegistry configRegistry, GC gc) {
ICellPainter painter;
int maxWidth = 0;
ILayerCell cell;
for (int rowPosition = 0; rowPosition < layer.getRowCount(); rowPosition++) {
[Updated on: Tue, 16 October 2012 16:55] Report message to a moderator |
|
|
|
| Re: column width [message #947058 is a reply to message #941791] |
Tue, 16 October 2012 19:25 |
Jay Norwood
Messages: 112
Registered: July 2009 |
Senior Member |
|
|
I tried your cellPainter example from the faq and added this code to the Big_data example. This works very much faster than the IOverlayPainter example that I experimented with. However, updates lag increasingly as you scroll to the right, and it seems to be related to the number of table columns. For example, if you change the Big_data example to have 1 Million rows and 1 Million columns, then scroll to the middle of the range on both horizontal and vertical, then scroll down single step takes on the order of 10 secs and scroll to right take on order of 5 secs. If you scroll to end of range on both, then scoll single step left takes about 11 seconds, and scroll single step up takes about 15 sec.
At the top of range on both bars, scroll single step down occurs immediately, scroll singe step right occurs immediately. So there is likely some code buried in there that is processing the whole table dimensions rather than just the viewed port.
final NatTable natTable = new NatTable(parent,layer,false);
ConfigRegistry configRegistry = new ConfigRegistry();
natTable.setConfigRegistry(configRegistry);
natTable.addConfiguration(new DefaultNatTableStyleConfiguration() {
{
cellPainter = new LineBorderDecorator(
new TextPainter(false, true, 5, true));
}
});
natTable.configure();
|
|
|
|
| Re: column width [message #947396 is a reply to message #947247] |
Wed, 17 October 2012 03:44 |
Jay Norwood
Messages: 112
Registered: July 2009 |
Senior Member |
|
|
I've done some investigation into the slower performance for the resize processing as the arrays get larger, and I suspect at least a part of the problem is explained by the implementation of the ColumnReorderLayer lookups. The cross-reference is being contained as an ArrayList, and the cross-reference lookups are being done using an indexOf operation, which iterates through the whole ArrayList looking for the first occurrence of the columnIndex. So as you operate on columns and rows that are at the upper ends of large row and column counts, you spend increasing time in this lookup. So columnIndexOrder needs to be converted to something that has constant lookup time.
public int getColumnPositionByIndex(int columnIndex) {
return columnIndexOrder.indexOf(Integer.valueOf(columnIndex));
}
I've confirmed this is the major problem. I added an int[] version of list and a reverse index int[] version of the list, and use those for the look-ups. Then on 100k by 100k grids, all the resize updates for a page are constant time anywhere on the grid and reasonably fast.
[Updated on: Wed, 17 October 2012 06:56] Report message to a moderator |
|
|
| Re: column width [message #948131 is a reply to message #947018] |
Wed, 17 October 2012 19:48 |
Jay Norwood
Messages: 112
Registered: July 2009 |
Senior Member |
|
|
Another place where InitializeAutoResizeColumnsCommand is causing a problem:
The Big_Data example has a million rows, and has an AutoResizeColumnAction action bound to the header in DefaultColumnResizeBindings. That action calls InitializeAutoResizeColumnsCommand, which makes the example hang while it looks at all the rows if you happen to double click on one of the column header separators.
A reasonable fix might be to limit the range of the rows inspected to the view or to some reasonable sized range that includes the view.
DefaultColumnResizeBindings
uiBindingRegistry.registerDoubleClickBinding(new ColumnResizeEventMatcher(SWT.NONE, GridRegion.COLUMN_HEADER, 1), new AutoResizeColumnAction());
InitializeAutoResizeColumnsCommand command = new InitializeAutoResizeColumnsCommand(natTable, column, natTable.getConfigRegistry(), new GCFactory(natTable));
The problem is because MaxCellBoundsHelper.getPreferedColumnWidths looks at all rows, which appears to hang on this million row example.
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.02329 seconds
] 
Search
Help
Register
Login
Home
