For those lurking, DayEditor (one of the CompositeTable examples) handles 7 columns by 50 rows okay, and that seems to be about the upper limit of what you can do with CompositeTable using a heavyweight control in each cell before performance starts to significantly degrade.
Patches to improve performance are welcome! :-) Best regards, Dave Orme ----- Original Message ----- From: [EMAIL PROTECTED] To: [email protected] Sent: Saturday, March 10, 2007 11:00:20 AM GMT-0800 Subject: nebula-dev Digest, Vol 12, Issue 8 Send nebula-dev mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://dev.eclipse.org/mailman/listinfo/nebula-dev or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of nebula-dev digest..." Today's Topics: 1. Re: [SPAM] [nebula-dev] [CompositeTable] very bad scalability (Andr? Dietisheim) ---------------------------------------------------------------------- Message: 1 Date: Sat, 10 Mar 2007 14:26:23 +0100 From: Andr? Dietisheim <[EMAIL PROTECTED]> Subject: Re: [SPAM] [nebula-dev] [CompositeTable] very bad scalability To: Nebula Dev <[email protected]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=utf-8 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 > [email protected] > https://dev.eclipse.org/mailman/listinfo/nebula-dev > > > !DSPAM:45f0a83319851044727653! ------------------------------ _______________________________________________ nebula-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/nebula-dev End of nebula-dev Digest, Vol 12, Issue 8 *****************************************
_______________________________________________ nebula-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/nebula-dev
