[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [SPAM] [nebula-dev] [CompositeTable] very bad scalability
|
Hi Andre,
what is the problem with CellEditors, I think we are in 3.3 very close
to provide Excel-Like features in SWT.
In 3.3M6 we are going to introduce the following:
- configureable editor activation (SingleClick,DoubleClick, ...)
- (configureable) keyboard cell navigation
- tabediting in cells
If you are interested please take a look at the following bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=172646
André Dietisheim schrieb:
Hi Dave, Hi Ivan
thanks a lot for your feedback!
I definitively underestimated the heavyweight-scalability. The widget I
need is a classic table (JTable, SWT Table) without any special
cell-capabilities. My choice towards Compositetable was due to the
presumed possibility to allow an Excel-like editability (no celleditors)
and the several bugs still present in virtual tableViewer.
In the tests (30*30 cells) I made, I get the best results when I use
canvas as cells, but the performance is still not fluid enough. I'll
have to decide on monday if I still use CompositeTable for the current
customer, but time is running and my customer change is due end of
march. I therefore probably will try to patch the current tableViewer
and try to fix the last documented bug. The time necessar for this try
is affordable. Another alternative would be to try to reimplement my
table using KTable that performs very well.
On the other hand, i still could get some regular worktime (after my
customer change) to continue compositeTable if I see a way to achieve my
goal to implement a large, cell-based table.
What about using canvas for rows and draw all cells with gc (or
draw2d-figures?) - similar to ktable? In this scenario all accesses to
column-'controls' would have to be refactored to a more generic
TableRow-class and a subclasses GridRowLayout could be used. I assume
the changes in CompositeTable would be very important but worth the
performance increase for regular tables. What do you think of this
approach?
Regards
André
On Thu, 2007-03-08 at 19:15 -0600, David J. Orme wrote:
1.) the whole rcp app dies with SWTError: no more handles
I'll analyze this by using sleak but I suppose that this will not
help a
lot as i'll reach the limit very soon by opening a second
editor-tab.
This lets me think that it's not possible to display cells by
individual
controls. On the other hand traversal relies on these controls. Any
ideas
here?
Yeah; since CompositeTable creates a control for every cell, you have
to be careful.
Thoughts: Can you reduce the number of native controls in your row
object? Maybe you can draw part of your row on a canvas rather than
making everything heavy-weight? This is how DayEditor (built on
CompositeTable) works.
Sometimes CompositeTable isn't the right solution. If you need
something that has to scale to lots of visible rows/columns, maybe
KTable or the SWT Table are the right solution.
2.) layout (I use native header) is terribly slow. The table takes
up to 2
minutes to display and resize.
I probably could solve that performance issue by improving the
resizing or
using another header. any ideas?
Layout should scale linearly with the number of controls. However,
CompositeTable uses lots more controls than other solutions. So
either you need to go less native (draw more stuff on a GC), have
fewer controls in a given table, or you need another solution.
Using another solution probably means either that you have to break
your table down into more smaller tables or you might need to use a
different table control.
Regards,
Dave Orme
!DSPAM:45f0a83319851044727653!
_______________________________________________
nebula-dev mailing list
nebula-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/nebula-dev
!DSPAM:45f0a83319851044727653!
_______________________________________________
nebula-dev mailing list
nebula-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/nebula-dev
