[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[nebula-dev] Re: nebula-dev Digest, Vol 12, Issue 8
|
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: nebula-dev-request@xxxxxxxxxxx
To: nebula-dev@xxxxxxxxxxx
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
nebula-dev@xxxxxxxxxxx
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
nebula-dev-request@xxxxxxxxxxx
You can reach the person managing the list at
nebula-dev-owner@xxxxxxxxxxx
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 <dietisheim@xxxxxxxxx>
Subject: Re: [SPAM] [nebula-dev] [CompositeTable] very bad scalability
To: Nebula Dev <nebula-dev@xxxxxxxxxxx>
Message-ID: <1173533183.12239.71.camel@pmobilead>
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
> 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
End of nebula-dev Digest, Vol 12, Issue 8
*****************************************
