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

List:       koffice-devel
Subject:    Re: Improving KSpread...
From:       Tomas Mecir <mecirt () gmail ! com>
Date:       2004-07-14 14:15:36
Message-ID: 492258b1040714071535bd5233 () mail ! gmail ! com
[Download RAW message or body]

On Tue, 13 Jul 2004 20:13:14 +0200, Ariya Hidayat <ariya@kde.org> wrote:
> 
> > Hrmpf. Is all that really needed? I mean, do we really need a
> > CellView object for each and any cell? And to create and delete those
> > objects all the time?
> You don't need to if proper pools system can be used (this is a matter
> of implementation, not design). Remember, the screen is limited, the
> number of cells you can see at one time isn't the number of cells in the
> worksheet. To put simply, imagine you have an array of the cell-views,
> each is ready to be associated with any cell you might have.
> You don't need to have a CellView object for each and every single cell,
> you just need enough of them, i.e. for cells that are visible to users.
> Less means performance penalty (due to two or more cells fighting each
> other to get one view), more does no harm except memory waste.

Ahhh. Now I understand. I thought it was meant otherwise. Yes, this is
a nice idea.

> In reality, there's too much stuff you need for painting that it's
> better to let it have access inside the data structure of the cell.
> I have never instrumented KSpread extensively but I guess (just a wild
> guess), repaint is slow because many extra unnecessary steps are carried
> out. Recall again my example on series fill, with CellView concept you
> don't need to calculate the layout (i.e. exact position of the text,
> correct font size, etc) until it's necessary.

Yep, you don't need it with my concept either. Actually, both my and
your concept should do quite well, the main difference is that in your
concept, you only store drawing information about visible cell. Hence,
you need less memory, but if you scroll up and down and then up and
again down and again and again, you need to recalculate all the stuff
again and again. Whereas in the concept of mine, you keep the painting
info of all the cells, and that versioning concept is used to prevent
us from having to update all the cell drawing info if you resize the
column or something. Therefore, my concept should usually be faster,
but it would require a lot more memory, yours might be slower in some
situations, but memory consumption shall be much lower.
I'd therefore prefer going with your concept, but trying to do things
in such a way, that parts of the concept of mine can be added where
the result seems to be too slow.

> Storing it in cm won't help the speed because we paint in pixels. The
> idea is to gain time in converting these values over and over again.

Yeah, sure. But we wouldn't be STORING in cm. We would be COMPUTING in
cm, then storing just the length of text that fits. Hence, we may find
out that the text requires 2.53 cm and that cell width is 2.535 cm,
hence we conclude that the text fits. And the text will then always be
displayed, even if one-pixel differences at various zoom level might
cause us not to display the text properly. Similarly, if we find out
that text width is 8.45 cm and that first 13 letters fit into 2.535
cm, we remember that first 13 letters should be displayed, but no
more, even if 14 would fit due to one-pixel changes after zooming.

> > The information should be cached and only recomputed when we find out
> > that row/col width has changed (here I would propose having "version"
> > info in each row/column object, initially 0, and whenever its size
> > changes, number will increase, each cell will then remember the
> > version of its row/col (cols, if spanning over multiple cells) at the
> > time of last computation.
> I don't really get this concept, but I guess using CellView simply
> removes the need to do so. This is because CellView should provide all
> necessary info for painting the cell, including the correspoding row and
> column format of that cell.

Yes, you are right. With CellViews taken in this way, there should be
no need to use this. But we may still need to use it, if we find out
that there are too many computations involved when creating the
CellView. Of course, this is not a matter of concern right now, we'll
care about that later on, when the basic stuff is done and when we
measure the speed of our new code.

> When you resize or change format of a column, almost likely that each
> cell in that column should be repainted, or at least its painting info
> be updated. But of course we can delay this precious step, until the
> cell is visible/exposed. "Damaging a column" means deleting cell views
> of cells in that particular column.

Yes, I understand it now. A pool of cellview object, that get
activated and deactivated as needed.

> > Oh, and btw, is there anything wrong with that patch I've sent a
> > couple of days ago, or is there just no time to have a look? ( btw2,
> > how much do I need to contribute before I can have my own CVS
> > account? :D )
> 
> I'll have a look first...

Alright :) I hope that there won't be too many problems with that :)
Oh, and I hope to have another patch ready by today or tomorrow...

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