Re: [Libreoffice-ux-advise] [Libreoffice] Performance improvements for calcs' sheet actions

Hello Christoph,

2011/6/5 Christoph Noack <christoph@dogmatux.com>

> Hi Markus, Kohei, all!
>
> Am Sonntag, den 05.06.2011, 13:23 -0400 schrieb Kohei Yoshida:
> > Hi Markus,
> >
> > On Sat, Jun 4, 2011 at 8:04 PM, Markus Mohrhard
> > <markus.mohrhard@googlemail.com> wrote:
> >
> > > I would like to here any suggestions before I change anything UI
> related.
>
> Cool :-)
>
> Although Kohei already proposed an alternative, I'd like ask you
> something. In you initial mail, you've stated "it turns out that we need
> much more time updating the progress bar than we need to move the
> sheet". How much is needed for such stuff - also considering rare cases?

The problem is that we have to differentiate between two cases. We have the
case with a lot of formulas, then most work is done in updating every cell,
if we have few formulas most work will be done relocating the sheet and at
the moment updating the progress bar.

> If we could guarantee that moving stuff around will never take more than
> (let's say) 1 second (complex document, old computer), then there is no
> need to visualize the status of this operation. If not, then the user
> has to be informed about that ... thus, Kohei's suggestion (as far as I
> understand it (I'm not a developer) sounds very reasonable.

Yes I think I have to implement Kohei's suggesstion. I think a slow
computer, several sheets and a lot of formulas will need some seconds. At
least it should be faster than in the 3.4 releases. My test case with 5000
empty sheets will need without a progress bar around 4 seconds and around 12
seconds with the progress bar.( I hope than no one will ever get the
impression that working with 5000 sheets is a normal use case for calc, it
just makes profiling much easier)

> > So, there are two things that I could see us changing.
> >
> > One is to update the progress bar only once per sheet, instead of once
> > per column in each sheet.  I find the latter simply a bit silly, not
> > to mention it has terrible performance consequences.
>
> [...]
>
> > The key is to not eliminate the progress bar, but simply reduce the
> > frequency of updating which can be very expensive especially when
> > using GTK to draw the progress bar.
>
> Cheers,
> Christoph