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

List:       koffice-devel
Subject:    KSpread 2.0: some issues
From:       "Ariya Hidayat" <ariya () kde ! org>
Date:       2006-11-29 22:55:45
Message-ID: ba035dd10611291455m60c86a18i7023fe654c553345 () mail ! gmail ! com
[Download RAW message or body]

Hi all,

Tonight Stefan and I had a discussion regarding some issues for the
upcoming KSpread 2.0. The summary follows. Feel free to give comments
and feedback.
Note: this stuff will eventually go to the KOffice wiki.


(1) SheetView

We agree to have a SheetView. A SheetView is associated with a Sheet.
The SheetView holds all CellViews of the cells in the sheet.

There are two opinions:

- Ariya thinks each sheet (in each view) should have its own sheet view.
The reason is just to keep the valid cell views in that sheet as long
as possible (until they are destroyed because they are invalidated or
removed from memory because the pool is full)

- Stefan thinks only the visible/active sheet needs to have a sheet view.
The reason is to minimize memory usage because at any given time, only
one sheet is visible.

(2) CellView

At the moment, there is one CellView for every visible cells, regardless
whether the cell is empty or not. Since CellView is used for painting (in
Canvas) and empty cell basically does not need so much thing, a shared
default CellView is used for all empty cells.

We need to extend CellView so that basically it has everything it needs to
paint the cells. Therefore all the necessary painting information will be
accessed only on its constructor. During its lifetime, it does not need
to access its associated cell or any other kind of information. It is
"on its own".

We won't update CellView at all. If the associated cell is marked as dirty
(the width is changed, a new style is applied, etc), then we simply destroy
it and then recreate the CellView whenever necessary.

Note that for painting a cell, the border of the neighboring cells must be
taken into account. However, CellView works only with "effective style" that
already handles neighboring cell and conditional formatting. On the other
hand, this means when we mark a cell as dirty, all the cell views of the
neighboring cells must be destroyed as well.

(3) Caching the complete style

At the moment, Stefan has already implemented a new style storage. In order
to speed up style look for specified cell, a cache system needs to be
implemented. This cache should store "final" style for a given cell.
The goal is to minimize the time to look-up the style (and substyles) in the
style storage.

The cache will be built right into the style storage. Possibly it will be
using QCache.

(4) High-precision calculation

This has been started by Tomas as the last part of his SoC 2005. At the moment
there is already ValueCalc which is responsible to perform calculation (like
addition and subtraction). All built-in functions such as sin, cos, etc have
been modified to use this ValueCalc class.

Ariya: rather than a run-time option, how about making it a compile-option?

The reason: it's a pity to see some FPU instructions (after compiled) such as:
  double u1 = pow((1+sqrt(5))/2, n);

is replaced by:
  Value u1 = calc->pow (calc->div (calc->add (Value(1), s), Value(2)), n);

Not only the latter is more verbose, it is also prone to mistake.

What if instead of using ValueCalc class, we fall back to a special class, let
us tentatively call it Float. This class should implement important operators
(through operator overloading) so that we can treat it like 'normal' number,
e.g:

  Float n;
  Float u1 = pow( (1+sqrt(5))/2, n );

If KSpread is compiled with support for high-precision (using GMP or whatever),
then class Float should wrap the number representation.

If not, then we can use:
  typedef double Float;

For standard math functions (like sine, cosine, etc), we can wrap it in special
namespace or class e.g. Math:
  Float u1 = Math::pow( (1+Math::sqrt(5))/2, n);

Without support for high-precision, this Math::sqrt just falls back to ::sqrt.

How about automatic value conversion? We can still make use of it. As
far as the
calculation concerned, we do not really need to perform (and detect) automatic
conversion *during* the long calculation but only when getting the function
arguments.

(5) Flake/KoText integration

Ariya and Stefan agree to wait a bit until KoText2 is stable enough.
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]