Bug 129552 - LO 6.4: form controls flicker, high cpu usage
Summary: LO 6.4: form controls flicker, high cpu usage
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.4.0.0.beta1+
Hardware: All Windows (All)
: medium normal
Assignee: Miklos Vajna
URL:
Whiteboard: target:6.5.0 target:6.4.0.2
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Form-Controls Regressions-ViewToDevice-Refactor
  Show dependency treegraph
 
Reported: 2019-12-22 17:28 UTC by Oliver Brinzing
Modified: 2020-02-10 13:23 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
flicker demo file (20.00 KB, application/vnd.oasis.opendocument.spreadsheet)
2019-12-22 17:28 UTC, Oliver Brinzing
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Oliver Brinzing 2019-12-22 17:28:59 UTC
Created attachment 156732 [details]
flicker demo file

The "form controls flicker, high cpu usage" problem seems to be back.

steps to reproduce:
- open attached spreadsheet
-> radio controls will flicker

reproducible with:

Version: 6.4.0.1 (x64)
Build-ID: 1b6477b31f0334bd8620a96f0aeeb449b587be9f
CPU-Threads: 4; BS: Windows 10.0 Build 18363; UI-Render: Standard; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: 

but *not* reproducible with:

Version: 6.3.4.2 (x64)
Build-ID: 60da17e045e08f1793c57c00ba83cdfce946d0aa
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: 

this seems to have started with:

https://gerrit.libreoffice.org/gitweb?p=core.git;a=commit;h=5b51aa12e8ebfa894ecfdd0c8c9004aa99e6f46d

commit 5b51aa12e8ebfa894ecfdd0c8c9004aa99e6f46d	[log]
author	Miklos Vajna <vmiklos@collabora.com>	Tue Mar 26 11:36:37 2019 +0100
committer Miklos Vajna <vmiklos@collabora.com>	Wed Mar 27 16:07:59 2019 +0100
tree 22579d695d43818ef802168ef97279c40114b6d9
parent 5f8aaa09d3d7fbf10446b085f9ace83c074a65c3 [diff]

tdf#123505 svx: fix invalidation loop caused by special form control geometry

Regression from commit d464d505fbf6e53a38afdd3661d320fac8c760d6
(Refactor calc non-linear ViewToDevice transform, 2018-10-12), the
problem was that the opengl menu was never painted from the starved idle
handler as a paint-invalidation loop starved the main loop.

ScGridWindow::Paint() called vcl::Window::ImplPosSizeWindow() for the
form control of the bugdoc, which triggered an invalidation -> paint ->
start again.

Checking what adjustControlGeometry_throw() did, the result of the
transformed points are quite close to each other, but not equivalent:

debug:18521:18521: adjustControlGeometry_throw: aTopLeft before transformation is (1773,426)
debug:18521:18521: adjustControlGeometry_throw: aTopLeft after transformation is (64.935,16.0382)
debug:18521:18521: adjustControlGeometry_throw: aPaintRectPixel is 952x586@(64,16)

If we round, rather than truncate, then the size of the control is
always the same, so no actual resize and invalidation happens during
paint.


/cygdrive/d/sources/bibisect/bibisect-win32-6.3
$ git bisect good 2ec3f0b0a0566c0fcb165d022e153a2dc2905db7 is the first bad commit
commit 2ec3f0b0a0566c0fcb165d022e153a2dc2905db7
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Wed Mar 27 08:54:42 2019 -0700
    source 5b51aa12e8ebfa894ecfdd0c8c9004aa99e6f46d
    source 5b51aa12e8ebfa894ecfdd0c8c9004aa99e6f46d

:040000 040000 adb50067ca87bb43313b51e49c73a747f4b89bcb 47f7cbc985a20111ffc35c747cf529ff0dfb2950 M      instdir

/cygdrive/d/sources/bibisect/bibisect-win32-6.3
$ git bisect log
# bad: [18f926e8e18b3d855c2f79ef279febbeb846b8cd] source 13152ad88b24cadc836a829b4424a72a152ca9b1
# good: [ea94942caaf195b8d8b2d5c2abb523359ab390e7] source a20a2d7e0d28658f2d9089da076961a599833a28
git bisect start 'master' 'oldest'
# good: [3aea60569b9190400409ebb93f0a5d323b6fc5d4] source 47ce4b87d8a13fc340794ffd9a10d5bd6a15e644
git bisect good 3aea60569b9190400409ebb93f0a5d323b6fc5d4
# bad: [3b794d71dd796e467baef082c140bdc77c69c979] source 47d25dc5abe000ce751cb1e4dbd1f85f7198ca05
git bisect bad 3b794d71dd796e467baef082c140bdc77c69c979
# good: [8adbffa485cdd6d5e13106e5f55e70249f46a4f6] source 15e9e6d12aa2d49e114ec0cf8326f2264ccf2640
git bisect good 8adbffa485cdd6d5e13106e5f55e70249f46a4f6
# bad: [446d84046fe885e09f7cb71061f6c80ff83137e3] source 5bd1caf14c8e297db229e9060a584386247e62b1
git bisect bad 446d84046fe885e09f7cb71061f6c80ff83137e3
# bad: [290c14249daec35d65309db03bbb2d8dd9577869] source a67125aa5c5ef8f2a19dcbcad778cd66a304761b
git bisect bad 290c14249daec35d65309db03bbb2d8dd9577869
# bad: [8893400736b4e45e29c30cf30ca8537d5f7688d4] source 92ce72a4731ad468f5928efd9da7fe66bfdb08ea
git bisect bad 8893400736b4e45e29c30cf30ca8537d5f7688d4
# good: [3d66d55d73ab46e044cfa3f0f113ea7fa16db0b7] source 93f0b6143822d171caf6cd3db10d4730e276dad9
git bisect good 3d66d55d73ab46e044cfa3f0f113ea7fa16db0b7
# bad: [e838c9ebf7cac8762d7fb143622bb76797c3e56c] source 3dfe2ce66ac220c8f137730d7146bc334c1859be
git bisect bad e838c9ebf7cac8762d7fb143622bb76797c3e56c
# bad: [a8f56f90bcebbdfbfe8248b2fe981737316af0f6] source f897e80d063436be07356049f595efe5afb04859
git bisect bad a8f56f90bcebbdfbfe8248b2fe981737316af0f6
# bad: [f400ff1767df5003a4ce7b182d12df0162efeedf] source 28eab5de358631758315a3581e860d6ef533259a
git bisect bad f400ff1767df5003a4ce7b182d12df0162efeedf
# bad: [52f6a8fc06840d36b1ac6ab8cb24ac9aa7db7ba0] source 58b3982a15eb55f2d4c364d256f37970e1390392
git bisect bad 52f6a8fc06840d36b1ac6ab8cb24ac9aa7db7ba0
# bad: [2ec3f0b0a0566c0fcb165d022e153a2dc2905db7] source 5b51aa12e8ebfa894ecfdd0c8c9004aa99e6f46d
git bisect bad 2ec3f0b0a0566c0fcb165d022e153a2dc2905db7
# good: [5c0ceb2e6e66d4a97f0925ab4e9f8165fee0a676] source 5f8aaa09d3d7fbf10446b085f9ace83c074a65c3
git bisect good 5c0ceb2e6e66d4a97f0925ab4e9f8165fee0a676
# first bad commit: [2ec3f0b0a0566c0fcb165d022e153a2dc2905db7] source 5b51aa12e8ebfa894ecfdd0c8c9004aa99e6f46d
Comment 1 Oliver Brinzing 2019-12-22 17:39:00 UTC
(In reply to Oliver Brinzing from comment #0)
> steps to reproduce:
> - open attached spreadsheet
> -> radio controls will flicker

I forgot to mention: 
You need to disable OpenGL - i cannot reproduce it with enabled OpenGL:

Menu Tools/Options.../LibreOffice/View
[ ] Use OpenGL for all rendering

also reproducible with:

Version: 6.5.0.0.alpha0+ (x64)
Build ID: 494e6a082c0186d7e54bc718439f79ed29471614
CPU threads: 12; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-US
Calc: CL
Comment 2 Xisco Faulí 2019-12-26 15:39:02 UTC
Reproduced in

Version: 6.5.0.0.alpha0+
Build ID: 1abfc8e2f677024ea058e96f3133e503ba89ea02
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: x11; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded

on mouse over

Adding Cc: to Miklos Vajna
Comment 3 Miklos Vajna 2020-01-03 10:09:53 UTC
Xisco: did you also confirm that this was fine before? I locally reverted the above patch on master (just the svx part) and I see that ScGridWindow::Paint() is still called in a loop. So I can confirm that there is a bug here, but I'm not sure if the above commit is the root cause and/or if this is a regression. Thanks.
Comment 4 Commit Notification 2020-01-06 10:25:02 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/e7e01efc56f7061d0a2e5142b4bae84dd403cc50

tdf#129552 sc: avoid infinite invalidation loop when the print range is empty

It will be available in 6.5.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 5 Miklos Vajna 2020-01-06 10:39:29 UTC
The commit message above contains the commit that I think is the actual root cause here; fixed anyway. :-)
Comment 6 Oliver Brinzing 2020-01-06 12:11:09 UTC
with 

Version: 6.5.0.0.alpha0+ (x64)
Build ID: f1604675e71c67024887d12bf73ccb86ac05a7a3
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-US
Calc: threaded

i can no longer reproduce this issue.
Comment 7 Xisco Faulí 2020-01-07 14:27:15 UTC
Verified in

Version: 6.5.0.0.alpha0+
Build ID: bf540873f5e258452fed5006f65a403c95e7872a
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: x11; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded

@Miklos, thanks for fixing this issue!!
Comment 8 Commit Notification 2020-01-07 15:51:26 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/8728eddf938c9c843ab72929cfd3947735ca8da2

tdf#129552 sc: avoid infinite invalidation loop when the print range is empty

It will be available in 6.4.0.2.

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

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