Re: [SPAM] [nebula-dev] [CompositeTable] very bad scalability

[André Dietisheim <dietisheim@xxxxxxxxx>]

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!