Bug 56613 - High CPU usage for the Copy animation in Calc
Summary: High CPU usage for the Copy animation in Calc
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected)
3.5.4 release
Hardware: x86 (IA32) All
: medium minor
Assignee: Not Assigned
: 73841 (view as bug list)
Depends on:
Reported: 2012-10-31 11:54 UTC by triggerds
Modified: 2016-04-26 14:16 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description triggerds 2012-10-31 11:54:21 UTC

The "caterpillar" animation for the copied selection in Calc eats lots of CPU, slowing all processes on modest computers.

To reproduce this:
- Open LibreOffice Calc on a new project,
- Select several cells
- Hit ctrl+C
- Look at CPU usage
- Hit escape
- CPU is low again.

It seems that the largest the selection is, the highest the CPU usage is. 

This has been tested on Ubuntu 12.04 and Debian testing, with and without 3D drivers installed on several computers. Not tested yet on Windows.

Thanks in advance, 

Comment 1 triggerds 2012-10-31 12:19:49 UTC
After testing, this CPU consumption is also present on Windows (Seven).
Comment 2 triggerds 2012-10-31 13:11:26 UTC
Still there too on
Comment 3 Jean-Baptiste Faure 2012-11-03 11:29:22 UTC
I do not reproduce with current release LO 3.6.3 nor the the master (Version (Build ID: 2a9fd5)) under Ubuntu 12.04 x86_64

That said, it seems that if use of anti-aliasing for graphics output (menu Tools > Options > LibreOffice > View) is activated, the CPU consumption is slightly higher.

Best regards. JBF
Comment 4 Roman Eisele 2012-11-14 18:11:36 UTC
(A Calc issue, therefore changed Component field accordingly.)
Comment 5 A (Andy) 2013-03-16 14:21:32 UTC
not reproducible with LO (Win7 Home, 64bit)
Comment 6 bfoman (inactive) 2013-05-13 12:32:02 UTC
Checked with:
Build ID: own W7 debug build
Windows 7 Professional SP1 64 bit

All I can reproduce is that when there is no selection CPU usage is 0, when some cells are selected it increases and when cells are deselected it is 0 again. I haven't notice any "It seems that the largest the selection is, the highest the CPU usage is" behavior.
Comment 7 gekacheka 2013-11-21 21:52:49 UTC
On LibreOffice running on WinXP sp3.

Steps to reproduce:

1. New Sheet (control-N)
2. Select All (control-A)
3. Copy (control-C)


CPU load goes up to maybe 35-40% (on an older laptop).

It especially occurs after control-A (select-all) copy selections,
even though no "racetrack" animation is visible in that case.
(No animated moving dashed line around selection, like marquee chase lights.)

The load is about the same after a 35-row by 12 column on-screen copy selection.


Very low CPU load (only for animation visible on screen, none if not visible).
(Load is near 0 for small copy selection animations around just a few cells.)

Other concerns:

From a user's perspective it can seem a little mysterious because clicking in a cell makes the shaded background selection go away, but the problem continues.  (Maybe because a thread continues drawing the invisible "racetrack" animation.)  A click in the input-line field will make it stop.

It is mildly annoying because it makes the fan louder.  It also shortens battery life.  So after copying data from one spreadsheet to another, when a user hears the fan running even though everything is idle, the user has to go back and find which Calc window still has a selection and click in the input line.

(I did not find an option to turn off this animation.  If the purpose of the high load is to make the user go back and do something to end the animation, stop the thread, and save the energy, it seems like there should be less annoying solutions, such as ending the animation after a period, just leave the dashed line.)
Comment 8 gekacheka 2013-11-22 00:16:39 UTC
Additional observations about the animation of the border around a selected spreadsheet region after a copy:

A single row of ~12 cells produces a CPU load of 8-11%.
A single column of ~35 cells produces a load of 5-8%.
But the region 35 rows by 12 columns produces a load of 35-40%.

(Guess: some graphics layer is redrawing the whole rectangle contents at each animation step, not just the border.  [The perimeter of the whole region is less than the sum of the perimeter of 1 row and the perimeter of 1 column.  If it was just drawing the perimeter, then the drawtime should be less than the sum.  But the region load is more than twice the sum of the row and column loads.])

(Some bits of code that look like they could be related to the animated dashed border:

ScOverlayDashedBorder in

OverlayManager in

Hope this helps someone figure out a fix.)
Comment 9 Tomaz Vajngerl 2015-03-08 14:19:59 UTC
*** Bug 73841 has been marked as a duplicate of this bug. ***
Comment 10 reint 2016-01-16 13:21:35 UTC

I am encountering this bug too. Now on: LibreOffice . The problem is less on LibreOffice . I am using gtk vcl but it also happens on gtk3. 

When copying more then 30 rows calc slows down so much it becomes unusable. On 4.4 that is after copying 50 rows. 

For me this bug is of major importance because I have to copy rows alot.

Please tell me if I can help with info or how to disable the dashed border animation. 

Comment 11 Cor Nouws 2016-04-26 14:16:13 UTC
Seeing this commit
I set this one to fixed.