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

["André Dietisheim" <dietisheim@xxxxxxxxx>]

Hi Tom

the progress on the bug you showed me is very promising! The 'problem'
with the current celleditors is a pure productivity issue in my
'database-browser' rcp-client. Users complain that my users feel like
there's one click too much, the one that's needed to activate the cell
editor (and there's a supplementary one when the celleditor has a dialog).
What they would like to have is something that feels like excel where you
just start to edit when you're there.

Greets
André

> 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
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>
> _______________________________________________
> nebula-dev mailing list
> nebula-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/nebula-dev
>
>
> !DSPAM:45f455ca81621058516758!


-- 
André Dietisheim
Stv-Bereichsleiter Products

Puzzle ITC GmbH
Eigerplatz 4
CH-3007 Bern
Telefon +41 31 370 22 00
Mobile  +41 76 423 03 02
Fax     +41 31 370 22 01

Puzzle ist Mitglied der ODF Alliance:
<http://www.puzzle.ch/odfalliance/>