[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: [kspread] - KSpreadCell simplification
From:       Philipp =?iso-8859-1?q?M=FCller?= <philipp.mueller () gmx ! de>
Date:       2002-12-12 17:34:30
[Download RAW message or body]

Am Mittwoch, 11. Dezember 2002 00:14 schrieb John Dailey:
> Hello list,
>
> A question for KSpread people -- does anyone see any problems/conflicts
> with your work if I were to move the KSpreadCell::makeLayout function and
> its helper functions to a new class (and possibly break it into smaller
> functions like I did with paintCell a while back)?

Yes, fine with me.

> Besides code simplification, this has the advantage of slimming down size
> of each cell a small bit. 

I think this is only the first step (replace member vars with member function 
calls of a format class) on the way to reduce the size per cell and use a 
more intelligent way to store the format information.

> There are some member variables that are set by
> this function and then used by the painting routine.  However there is no
> need to store them in the cell because they are used right after they are
> calculated and then must be recalculated on virtually any change to the
> cell.

Yes, but it is not for the case of a change of a cell. It's that they don't 
need to be recalculated on each repaint.

> So far I've identified the following variables as possibly needing removed:
> m_nbLines
> m_dTextX
> m_dTextY
> m_dOutTextWidth
> m_dOutTextHeight
> m_fmAscent
> m_strOutText (maybe -- need to be sure on this one)

I rethought this over and over again and finally I'm convinced that it doesn't 
help us to store them at all.
If we sooner or later want to have support for filled cells in >32k rows, then 
for 99% of the content of our workbook these values are not used at all (add 
other non visible sheets of the map as well). So it doesn't make sense to 
store them in the cell, or to store them in a reference (even the reference 
would waste memory).
Either we recalculate them on each paint or we keep a matrix in KSpreadView, 
which hold these values (but this is very complex to keep in sync).

I think let's remove them now and if performance is too bad, let's use a 
matrix in KSpreadView.

> BTW, I've indended this on the head branch, not the bug-fix branch.

Hehe, you should have seen my comments, if you would have dared to commit it 
to the BRANCH ;-)

Philipp
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]