Bug 102347 - Changing text font maxes out a CPU core and makes UI refresh sluggish
Summary: Changing text font maxes out a CPU core and makes UI refresh sluggish
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.3.0.0.alpha0+
Hardware: All All
: highest critical
Assignee: Caolán McNamara
URL:
Whiteboard: target:5.3.0 target:5.2.3
Keywords: bibisectRequest, perf, regression
Depends on:
Blocks: CPU-AT-100%
  Show dependency treegraph
 
Reported: 2016-09-22 03:10 UTC by Yousuf Philips (jay) (retired)
Modified: 2017-10-29 18:54 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
sample (11.87 KB, application/vnd.oasis.opendocument.text)
2016-09-22 03:10 UTC, Yousuf Philips (jay) (retired)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2016-09-22 03:10:25 UTC
Created attachment 127539 [details]
sample

Steps:
1) Open attachment
2) Select all the text and change the font name in the toolbar
3) One CPU core maxes out at 100% and UI doesnt refresh properly (e.g. alt+tab back and forth and it wont redraw the document, but will show the blinking cursor)

Regression as this doesnt happen in 5.2 daily.

Version: 5.3.0.0.alpha0+
Build ID: dec8da2a9aadbb6758ee76c30582bd8620a10ecb
CPU Threads: 2; OS Version: Linux 3.19; UI Render: default; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-09-21_05:53:33
Locale: en-US (en_US.UTF-8); Calc: group
Comment 1 Michael Meeks 2016-09-22 08:57:18 UTC
Interesting indeed; would love to have this bisected ... thanks =)
Comment 2 m_a_riosv 2016-09-22 12:16:14 UTC
I can't reproduce with:
Win10x64
Version: 5.3.0.0.alpha0+
Build ID: 3287bc2f91438085b7604773d5e0346fc3c3f452
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-09-18_05:11:16
Locale: es-ES (es_ES); Calc: CL
Version: 5.3.0.0.alpha0+
Build ID: 4c70a1a6666a079872b8f1966bd398e924dc1d1a
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-09-22_06:54:24
Locale: es-ES (es_ES); Calc: CL

In my I3 2-3% of cpu usage.

Maybe only Linux issue.

There are some things really slow first time LibreOffice is open, more visible in master, i.e.  selecting in context menu character or paragraph options, or in calc the format option.

Reported bug, perhaps in relation:
https://bugs.documentfoundation.org/show_bug.cgi?id=98132
Format cell dialog very slow to pop up

I can't find now but I think there was some bug about the slowness on load font list first time.
Comment 3 Caolán McNamara 2016-09-22 15:59:57 UTC
I thing this is a problem from...


commit 6dc1d2706f519d91617ac1a12fc2051d97ef98c0
Author: Caolán McNamara <caolanm@redhat.com>
Date:   Mon Jun 15 10:56:33 2015 +0100

    another stab at tdf#91393
    
    block paints only if the new requested size is larger than the original and
    unblock on explicit expose events as well as configure ones
    
...

commit 8f324aebfb94c4b2023894121b954ad4f35eb395
Author: Caolán McNamara <caolanm@redhat.com>
Date:   Sun Jun 14 15:49:56 2015 +0100

    Resolves: tdf#91393 autotext (etc) not fully drawn

...

commit e6a1956034c98204e30b0ca40330249d6f6f8155
Author: Jan Holesovsky <kendy@collabora.com>
Date:   Fri Jun 12 15:36:03 2015 +0200

    tdf#91301: Don't cache incomplete tabs.
    
    After introduction of the Idle processing, something has changed so
    that the underlying GetGdkWindow() does not update its size fast enough;
    even though the gtk_window_resize() is called before the Window::Erase()
    (that actually paints the background) etc.


i.e. if you resize the window slightly when cpu is 100% it'll jump back down to low load afterwards
Comment 4 Commit Notification 2016-09-22 16:25:42 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=99ee7deaf0a7a61bc74e8cb2d8a654fb675f50bb

Resolves: tdf#102347 configure size/expose might never come...

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 5 Caolán McNamara 2016-09-22 16:27:52 UTC
remove this wrong-direction broken stuff. I don't see the original problems anymore to see if they need an additional fix of some other kind.
Comment 6 Commit Notification 2016-10-06 14:26:55 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3e441af7c12e408a886256a55c34780699af7e2a&h=libreoffice-5-2

Resolves: tdf#102347 configure size/expose might never come...

It will be available in 5.2.3.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.