[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-03 2:25:43
[Download RAW message or body]

> Also, this is more ment like a first step to start working on it. There is
> still room for improvements, tuning,... I didn't want to have something
> perfect for all aspects from the beginning, because you might never meet
> the end if you try to do that.
> And if we decided to do something completely different it wasn't a too big
> waste of time.
I agree in getting a start down in CVS and then working from there. 

>
> > As for meeting, occasionaly I'm hanging at #koffice at irc.kde.org. Feel
> > free to go there if you have some time.
>
> Ok, thanks.
As soon as I figure out how to work irc i'll try it out  :-)

>
> > > Maybe I'll make my solution a little bit simpler for now, commit it and
> > > then we can discuss from that point on. I think "Style" is good name
> > > for it, but I'm open to change it anytime if we decide to. It's just a
> > > name for now...
> >
> > Okay. And I'd like to hear also opinion from others, notably John.

I haven't thought too much about sharing/reference counting.  But I have been 
kicking around some other ideas.  I haven't really thought these through but 
I'll get them out and get some help picking through them to see what is 
worthwhile.

As someone else mentioned before, I like the idea of having separate value, 
formatting, and layout (style?) objects -- all with the concept of a 
'default' in the same way that the 'default cell' has always been 
implemented.  I would like to see for any user operation some kind of call to 
KSpreadDocument to a 'begin' and 'end' function.  While the change is 
happening, all that should happen to the cell is having flags set (calc 
dirty, layout dirty, painting dirty), and the information about the change.  
We need to remove all calls to calc(), makeLayout(), paintCell(), etc.  until 
during the 'end' call in KSpreadDocument which then repaints cells that are 
currently visible.  So each cell is only going to be calculated once, only 
painted once for each view, and only if it is within the viewport of a view.

Also, once we get these styles working, I'd like to see some functionality to 
merge styles or layouts or formatting.  This is for formatting applied to a 
row or column.  Right now applying formatting to a row means applying that 
formatting to each individual (nondefault) cell that is in that row.  I think 
it would be more efficient to have cells 'merge' formatting from what is 
recorded for that particular cell, the row, and the column.  So if the row 
has font Helvetica and the cell has text color red, the result will show red 
Helvetica text.  And if the row formatting has green text and the cell has 
red text, it would just be red, or maybe whichever was applied more recently 
-- this is a sticky point for this idea.

Also, thanks for the link to gnumeric dependancies Ariya!  I looked into that 
and they store dependancies on the table level with a hash, not at the cell 
level.  For now I don't see a compelling reason to change how we store them 
in lists in each cell.  Once we clean up the execution path for calculating 
cells I don't think dependancies will be much of an issue.

What was our long term plan for solving the zooming problem?  Were we planning 
to try and paint everything in zoomed coordinates, or find a way to scale the 
canvas?

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