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

List:       koffice-devel
Subject:    Re: improving speed of painting
From:       Norbert Andres <nandres () web ! de>
Date:       2002-09-02 19:44:35
[Download RAW message or body]

>
> I'm also working on KSpreadFormula which implements formula parsing and
> evaluating. Sadly, we need to dump the use of KoScript if we feel speed is
> important. KoScript is (amazingly) too powerful to evaluate math
> expression. My KSpreadFormula uses a stack-based virtual machine approach.
> Just give me a week or two to complete its basic functionalities.
A "on-the-fly" evalution would be great: like in Excel:
write a formula in the "Edit Field", like "=A1+14+sum(B2:B14)", mark "A1+14", 
press F9 and Excel replaces this part of the formula with the real value. 
Escape and you get back to the old form.
This is really great for debugging.

>
> Another TODO is KSpreadFormat for defining format, i.e the way data (or
> value from KSpreadValue) is represented. For the sake of memory
> consumptions, KSpreadFormat should be shared as well.
I'm already working on this - I call it "Styles".
I splitted the things up in 5 styles: border, back, format, font and position 
(like OpenOffice) - in the beginning I needed it only for the OpenCalc filter 
:-) but it fixed other bug reports as well and we can have real styles for 
cells, like "Default", "Header",...

I have a first prototype, but painting is terrible right now, so I will need 
at least 2 more weeks for that to fixed the biggest issues.

I used the dependancy.ksp file (we used for debugging and testing): the size 
is about 35 %, loading is > 30% faster (most of the time we spend in the 
recalc after loading), and just 3 font styles are used for the whole 
spreadsheet!


>
> In the future, I expect KSpreadFormula to be shared (using refcount). This
> way, copying one cell's fomula to other hundreds cells only keep one
> formula in memory (providing that certain things are properly taken care).
>
> Looking at Gnumerics, seems that it's also a good idea to share layout
> (KSpreadLayout) among cells. But IMHO this will require a big changes since
> KSpreadLayout is the base class for KSpreadCell and friends.
>
> Note: in Gnumeric, even string is shared. Thanks to our QString, we have
> one less to care :-)
>
> Another problem is dependency. I'll expect we should have better and more
> efficient dependency handling, either improving what we already have or
> implementing a new stuff. Could possibly someone invest his time on
> examining Gnumeric's dependency code ? IIRC even it's more or less quite
> documented.
>
> > but don't do it like we do it with embedded objects: they are all stored
> > in koDocument and for every painting we go through the whole list to see
> > which objects are on the current table.
>
> That depends on how we would handle that. I'm not really get into this at
> the moment, but I'm quite sure we will have a solution. Maybe David,
> Laurent, Rob, or others have an idea ?
>
> > The problem here is that we will have to repaint everything if zoom gets
> > changed. So will it help?
>
> Repaint everything is OK. What I don't like is refreshing the display each
> time after repainting a cell. Isn't QWidget double-buffered somehow ?
>
> > Don't even know what an item-based canvas is :-) Sorry.
>
> Hmm, look-up Qt's QCanvas and QCanvasItem for detailed description. I was
> also informed by Rob that Gallium currently working on Kanvas, KDE-style
> canvas ala GnomeCanvas. From a short chat at #kde with Gallium, seems
> Kanvas is still not really usable so I was suggested to start with QCanvas
> first. OTOH, QScrollView is also a possible way to go.
> Whichever solutions we take, this must be discussed well first. I volunteer
> to do some research on this, but since I'm quite new to this
> painting/rendering stuff, nevertheless I'll appreciate any support.

_______________________________________________
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]