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

List:       koffice-devel
Subject:    Re: [kspread] insertRow doesn't update dependencies (patch)
From:       Philipp =?ISO-8859-1?Q?M=FCller?= <philipp.mueller () gmx ! de>
Date:       2002-10-11 14:40:17
[Download RAW message or body]

John,

nice to hear from you
.
> > And those are *big* repaints (all cells, not only visible cells!).
> > This is because KSpreadSheet::update iterates over *ALL* cells, not only
> > the visible ones. I don't know how to fix that - does that sound
possible?
> >
> > But anyway, I don't see the need for a big repaint

<snip>

> It won't repaint everything unconditionally -- here's what I am in the
process 
> of working on:
> No painting is done until the endoperation call.
> No cell is repainted unless the paintdirty flag is set for that cell in
the 
> KSpreadSheet.  In other words the processing functions set that flag in
the 
> same way they set calcdirty or layoutdirty when those conditions happen.

Calcdirty and Layoutdirty are different here, as calcDirty is used for cells
which must exist already. Dunno for layoutDirty, but layout is intended to
change anyhow.

I don’t like a paintDirty flag stored in the cell itself. Reason: Most of
visible cells are normally empty and these cells are currently in the cluster
as a NULL value. So if you want to store a flag there, you need to generate
the cell first. This will lead to a lot of cell objects generated only for
storing this tiny flag, as the rest of the cell is empty.

Please store this in a dedicated matrix or whatever you prefer to use.
Additional the matrix should only contain the visible screen cells, not all cells
of a sheet.

Update to a previous mail of mine here:
For scrolling we use canvas->scroll() (which in fact is widget->scroll),
which is a kind of bitblt. No need to update all cells here, only the new cells
are to be painted.

> As it is currently, the repaint happens immediately whenever some onscreen

> item changes which usually results in many repaints as one large operation

> will alter a cell several times.  I intend to remove the
KSpreadSheet::update 
> function entirely.

Principally fine with me, as long as we don’t use cell->flag but a kind of
matrix->flag.
I like such a approach were we have full control about the cells to be
repainted.
Especially, because we then know on the paint event which cells will be
repainted and for example don't need to repaint borders twice.

> I finally have a completely open weekend coming up so I should be able to
get 
> it done.

Thanks for your work so far,

Philipp

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!

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