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

List:       koffice-devel
Subject:    Re: improving speed of painting
From:       John Dailey <dailey () vt ! edu>
Date:       2002-09-02 6:37:07
[Download RAW message or body]

> 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.
We should probably decide who will do what or likely one of us is wasting our 
time.

>
> > - 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 believe Norbert is working on that already, too.

>
> 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.
Is this a good idea?  The formula parser definitely needs updating, but one 
major request is the ability to write their own formulas.  For that, we'll 
need more of the parser than is probably worth writing from scratch.  Perhaps 
we could use a combination of them both, but I don't think the speed of the 
koscript parser is an issue.  

On load, the only real problem is the XML parsing.  On huge spreadsheets, 
almost all the time waiting for it to load is before the progress bar begins 
counting.  Once it starts, the loading finishes soon afterwards.  In the 
code, the progress bar isn't started until after the file is done parsing 
into the DOM element.


>
> 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.

I haven's looked at gnumeric, but I know that in KSpread, all we really need 
to keep track of is for each cell, 'which cells depend on my value'.  This 
prevents a full scan of the spreadsheet when a cell gets a new value.  Right 
now we also keep a list of 'which cells do I depend on'.  This is unnecessary 
since those values can be calculated on demand through the koscript parser.

> 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 ?

I believe this is the result of an overly complex KSpreadCell where there 
really isn't a clear path of execution when moving from updating a cell to 
painting the change onscreen.  I think once we separate out the value, 
formatting, and style of cells, we can build a much cleaner system for 
painting

>
> > 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.
I don't know much of anything about the rendering either  :-)

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