After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 603813 - gnumeric: moving around the spreadsheet slow after last upgrade
gnumeric: moving around the spreadsheet slow after last upgrade
Status: RESOLVED FIXED
Product: libgoffice
Classification: Other
Component: General
0.7.x
Other Linux
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2009-12-04 19:38 UTC by Miernik
Modified: 2009-12-05 15:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
might fix the issue (491 bytes, patch)
2009-12-05 08:46 UTC, Jean Bréfort
committed Details | Review

Description Miernik 2009-12-04 19:38:26 UTC
I am using Debian sid. After I did upgrades of these packages:

gnumeric 1.9.15-1 -> 1.9.16-1
gnumeric-common 1.9.15-1 -> 1.9.16-1
libgoffice-0-8 0.7.15-1 -> 0.7.16-1
libgoffice-0-8-common 0.7.15-1 -> 0.7.16-1

moving the cursor around the spreadsheet became sluggish. I am talking
about moving around which does not cause the spreadsheet to scroll, lust
moving around fields in the same visible area.

How slow it is?

Well, before the upgrade, when I keep my down-arrow pressed, it took 3
seconds to move down 75 lines. After the upgrade it takes 10 seconds to
do the same.

Downgrading just gnumeric and gnumeric-common packages DOES NOT make it
fast again, but then downgrading also libgoffice-0-8 DOES make it fast
again. I did downgrade only gnumeric, gnumeric-common, and
libgoffice-0-8, but not libgoffice-0-8-common (aptitude somehow allowed
it and the spreadsheet worked, and was fast again). After upgrading all
three back again - slow again. 3 seconds vs. 10 seconds is a lot of a
difference, and is annoying.

The machine is a Athlon64X2 4000+ with 10 GB of RAM and the videocard
is one with 32 MB of RAM like this:

01:08.0 VGA compatible controller: Number 9 Computer Company Revolution 4 (rev 02) (prog-if 00 [VGA controller])
        Subsystem: Number 9 Computer Company Device 0017
        Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 15
        Memory at f0000000 (32-bit, prefetchable) [size=32M]
        Memory at f2000000 (32-bit, prefetchable) [size=32M]
        Memory at f501b000 (32-bit, non-prefetchable) [size=4K]
        Memory at f5000000 (32-bit, non-prefetchable) [size=64K]
        I/O ports at 9000 [size=256]
        [virtual] Expansion ROM at f4000000 [disabled] [size=64K]
        Capabilities: [80] AGP version 1.0
        Capabilities: [90] Power Management version 1

This video card is driving a SiliconGraphics SGI 1600SW LVDS panel.
Comment 1 Jean Bréfort 2009-12-05 08:37:52 UTC
Looks that the only explanation is the new call to goc_item_invalidate from goc_item_bounds_changed. Anyway I don't see such a large slowdown, but this might be architecture or video card dependent.

Can you build from source after commenting out the call to goc_item_invalidate line at goffice/canvas/goc-item.c, line 522, and test if this fixes the issue?

This call fixed a bug that might be addressed another way.
Comment 2 Jean Bréfort 2009-12-05 08:46:35 UTC
Created attachment 149136 [details] [review]
might fix the issue

Try this patch instead, please.
Comment 3 Jean Bréfort 2009-12-05 15:37:58 UTC
Considering fixed. Please reopen if the issue persist in next release.