[Qt4-feedback] QTableView and QTableWidget performance

[Sebastian Sauer]

On 12/19/2011 11:52 PM, Jaroslaw Staniek wrote:
> On 19 December 2011 21:47, Harri Porten<porten at froglogic.com>  wrote:
>> On Mon, 19 Dec 2011, Carl Schumann wrote:
>>
>>> I am working on an application for which a QTableWidget or QTableView
>>> would be the obvious to me choice.   Unfortunately, I get sluggish
>>> behavior.   I took a look at KOffice's spreadsheet program, kspread.
>>> It also has a need for a similar user interface and its performance on
>>> my systems is acceptable.   When I dig into the kpsread code it appears
>>> they are not using the QTableWidget or QTableView for the sheets in the
>>> workbook, but instead using lower level Qt to manage the sheet user
>>> interface.
>>>
>>> Am I correct that KOffice does not QTableWidget/View for the sheets
>>> UI?   Was this done for performance reasons?
>>
>> The main reason is an historic one: KSpread started in KDE 1 times which
>> predates the Qt 2 QTable class and particularly the Qt 4 item view classes.
>> Apart from the required porting effort performance (and customization
>> possibilities) might be reasons but even then, the QTable* classes aren't
>> necessarily unsuitable for bigger amounts of data.
> Yes :)
> Exactly the same goes to KexiTableView (for database tabular view) but
> in this case the data chunks can be way bigger than in spreadsheets.
>
> (CCd to calligra-devel at kde.org)
>

I think one of the problems lays in interview aka Qt's model/view 
separation. In KSpread (or Calligra tables how it's named this days) we 
have a high demand for repeating data where properties, content, styles 
for a cell are shared between multiple cells. To enable this we do not 
feed the view just with the data from one model but we actually spit the 
data into different models (aka storages in Tables) and each of them is 
able to define a region and not only a single cell where that data 
should be applied to. Those repeating-cells informations are then used 
in both on one hand in the model to store and receive those informations 
only one for a region and in the view to display it only once but "copy" 
the display result over (not exactly the case but explaining it in more 
detail would be a bit out of scope).

OpenOffice.org Calc or Libreoffice Calc do very much the same. MSOffice 
has a better design here in that it shares content independent of the 
neighborhood where that content is located. That means they do not 
define repeating regions but shared content. In a similar way like us 
they also do that on a fine-granulate base means they can 
shareindependentlya formula, a number, text, style, formatting, etc. for 
each cell with other cells.

I think the concept of repeating or shared content is rather essential 
for dealing with large amount of data and more so in the case of 
spreadsheets where repeating content is more the rule then an exception. 
The second more obvious thing and to my knowledge already done by 
interview is to load/fetch/display/etc. only those data that is visible.

Hope that helps. Greatings from the Calligra Suite developer-team :-)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20111220/1d9450e5/attachment.htm>