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

List:       koffice-devel
Subject:    Re: improving speed of painting
From:       Ariya Hidayat <ariya () kde ! org>
Date:       2002-09-02 2:42:19
[Download RAW message or body]


> - save the formula result as an attribute to the text (not
> the way it is now: additional QDomElements mean additional parsing time)
> and really use the result on load (no recalc) => just update the
> dependancies on load. (I would volunteer to do this) Loading time should be
> half of the time it takes right now.

I'm working on KSpreadValue class, and John has expressed interest as well. So 
possibly you can give us a hand, too. Any value, either from user input or 
formula calculation, should be put in an instance of this class.

> - remove all members in KSpreadLayout => it takes to much time to create 7
> Pens, a brush and all the other stuff, put it in style classes (I will do
> that) => insert a series with creating 10000 cells => most of the time we
> spend in creating the layout classes. Also: this will make the file size
> much smaller => less loading time, less memory usage,...

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.

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.

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.

-- 
"One OS to rule them all, One OS to find them,
One OS to bring them all and in the darkness bind them."

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