Bug Hunting Session
Bug 121963 - button flashing - mouse wheel zooming breaks
Summary: button flashing - mouse wheel zooming breaks
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.3.0.0.alpha0+
Hardware: All All
: highest critical
Assignee: Armin Le Grand
URL:
Whiteboard: target:6.4.0 target:6.3.4
Keywords: bibisected, bisected, regression
: 122083 122644 122713 125720 126558 126778 126845 126987 127067 127155 127352 127444 127503 127563 127636 127828 127842 128093 128107 128147 128151 128326 128368 128685 (view as bug list)
Depends on:
Blocks: Form-Controls ViewToDevice-Refactor
  Show dependency treegraph
 
Reported: 2018-12-07 16:00 UTC by raal
Modified: 2019-12-02 13:37 UTC (History)
39 users (show)

See Also:
Crash report or crash signature:


Attachments
perf flamegraph (241.15 KB, application/x-bzip)
2019-10-24 17:26 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description raal 2018-12-07 16:00:10 UTC
Description:
button flashing

Steps to Reproduce:
Open file from bug 121919  https://bugs.documentfoundation.org/attachment.cgi?id=147324
Sheet Session Scores, see button  "Calculate Scores"

Actual Results:

actual result
text is blinking /button flashing
If the problem is not visible Zoom in


Expected Results:
button without movement 


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 raal 2018-12-07 16:01:36 UTC
This seems to have begun at the below commit.
Adding Cc: to Armin Le Grand ; Could you possibly take a look at this one?
Thanks

8a7827fc2caad9893cd7583be164ca5cd115a999 is the first bad commit
commit 8a7827fc2caad9893cd7583be164ca5cd115a999
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Thu Nov 29 00:31:25 2018 +0100

    source sha:d464d505fbf6e53a38afdd3661d320fac8c760d6
author	Armin Le Grand <Armin.Le.Grand@cib.de>	2018-10-12 11:13:09 +0200
committer	Armin Le Grand <Armin.Le.Grand@cib.de>	2018-11-27 11:33:10 +0100
commit	d464d505fbf6e53a38afdd3661d320fac8c760d6 (patch)
tree	3bf7db8591172bf948198f19d36df5df886486bb
parent	3e1e2b6687b0259ae28441cc0d314de0d908776b (diff)
Refactor calc non-linear ViewToDevice transform

Tested on windows and Linux
Comment 2 raal 2018-12-16 16:56:54 UTC
*** Bug 122083 has been marked as a duplicate of this bug. ***
Comment 3 Xisco Faulí 2018-12-20 12:54:09 UTC
I do reporudce it if I zoom in

Version: 6.3.0.0.alpha0+
Build ID: 1b7bcaa714f0af45c6a9660d1f0940cb7931ba0f
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded
Comment 4 Xisco Faulí 2019-01-15 17:44:55 UTC
*** Bug 122644 has been marked as a duplicate of this bug. ***
Comment 5 Rainer Bielefeld Retired 2019-04-26 17:48:41 UTC
REPRODUCIBLE with Version: 6.3.0.0.alpha0+ 
Build ID: 2e3b0c5d42d60d46cd9f8b8eda9424b095c63418; Windows 6.1
and own sample document with form controls
Comment 6 Xisco Faulí 2019-06-26 11:34:41 UTC
The mentioned commit also breaks the mouse wheel zooming if there is a button on the spreadsheet. Increasing severity towards 6.3 release
Comment 7 Oliver Brinzing 2019-07-26 12:28:42 UTC
*** Bug 126558 has been marked as a duplicate of this bug. ***
Comment 8 Oliver Brinzing 2019-08-08 12:53:56 UTC
this issue is reproducible with release:

Version: 6.3.0.4 (x64)
Build-ID: 057fc023c990d676a43019934386b85b21a9ee99
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc:
Comment 9 Oliver Brinzing 2019-08-09 12:53:24 UTC
*** Bug 126778 has been marked as a duplicate of this bug. ***
Comment 10 Xisco Faulí 2019-08-12 10:32:48 UTC
*** Bug 126845 has been marked as a duplicate of this bug. ***
Comment 11 Jean-Baptiste Faure 2019-08-17 14:48:17 UTC
*** Bug 126987 has been marked as a duplicate of this bug. ***
Comment 12 Jean-Baptiste Faure 2019-08-17 14:52:42 UTC
In addition to the button flickering, we have 100% CPU consumption.

Tested in Version: 6.3.2.0.0+
Build ID: 97b6565f27acad7288de016530c753f27f9d55f9
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Ubuntu_18.04_x86-64
Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US
Calc: threaded

Best regards. JBF
Comment 13 Oliver Brinzing 2019-08-26 05:24:05 UTC
*** Bug 127155 has been marked as a duplicate of this bug. ***
Comment 14 Xisco Faulí 2019-09-05 11:43:29 UTC
*** Bug 127352 has been marked as a duplicate of this bug. ***
Comment 15 Jaise James 2019-09-09 09:48:37 UTC
In calc Side bar, cell appearance - > cell border line style[ on adding any cell border enable it] flickering continuously.
Comment 16 Oliver Brinzing 2019-09-09 17:05:29 UTC
*** Bug 127444 has been marked as a duplicate of this bug. ***
Comment 17 Aron Budea 2019-09-12 00:30:18 UTC
*** Bug 127503 has been marked as a duplicate of this bug. ***
Comment 18 Oliver Brinzing 2019-09-16 17:06:00 UTC
*** Bug 127563 has been marked as a duplicate of this bug. ***
Comment 19 Xisco Faulí 2019-09-17 13:50:05 UTC
*** Bug 127067 has been marked as a duplicate of this bug. ***
Comment 20 Oliver Brinzing 2019-09-19 16:14:20 UTC
*** Bug 127636 has been marked as a duplicate of this bug. ***
Comment 21 Xisco Faulí 2019-09-27 17:58:17 UTC
*** Bug 127828 has been marked as a duplicate of this bug. ***
Comment 22 office 2019-09-27 18:42:46 UTC
Is there any (alpha, daily) version that has some kind of fix for this Bug to test if it's working. I would test it asap ;-)
Comment 23 Xisco Faulí 2019-09-30 10:38:19 UTC
*** Bug 127842 has been marked as a duplicate of this bug. ***
Comment 24 burnuser 2019-10-08 11:59:24 UTC
LO 6.3.2.2 German on Win 10 x64:
a) flickering Form-Button
b) flickering colors in color palette while moving mouse over colors
c) flickering in selection drop down - Line style/width (Calc cells + graphic elements)

+ CPU = 30% while doing nothing!
Comment 25 Xisco Faulí 2019-10-11 12:47:51 UTC
*** Bug 128093 has been marked as a duplicate of this bug. ***
Comment 26 tim 2019-10-11 13:03:23 UTC
If only I had search for 'flicker', instead of 'shake' or 'vibrate', I wouldn't have raised a duplicate.   Sorry.

But it is still a current issue on:
Version: 6.3.2.2
Build ID: 1:6.3.2-0ubuntu0.19.04.1~lo1
CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: x11; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-GB
Calc: threaded
Comment 27 Steve 2019-10-11 13:33:21 UTC Comment hidden (off-topic)
Comment 28 Julian Ragan 2019-10-15 11:17:28 UTC
I have narrowed it down to the following:
If a form has more than one control and in the underlying sheet column width in any one column is set to different than default, then all controls on the form start (not always immediately) to refresh (redraw) in a continuous loop affecting overall performance.

Steps to reproduce the bug:
1.Create new sheet
2.Add two controls to the form
3.Resize a few columns on the sheet

If all columns have default width this bug will not manifest itself.
If there is one control on the form, this bug will not manifest itself.

Reproducibility is a bit sketchy, since sometimes it starts to continuously refresh immediately and sometimes it takes a few seconds to catch on.
Comment 29 Oliver Brinzing 2019-10-15 16:31:40 UTC
*** Bug 128147 has been marked as a duplicate of this bug. ***
Comment 30 Oliver Brinzing 2019-10-15 16:41:27 UTC
*** Bug 128151 has been marked as a duplicate of this bug. ***
Comment 31 Oliver Brinzing 2019-10-15 16:46:32 UTC
(In reply to Julian Ragan from comment #28)
> If all columns have default width this bug will not manifest itself.

confirming, root cause seems to be the column width.

please have a look at:
https://bugs.documentfoundation.org/show_bug.cgi?id=128151#c1
Comment 32 Xisco Faulí 2019-10-22 17:10:41 UTC
*** Bug 128326 has been marked as a duplicate of this bug. ***
Comment 33 Elizabeth Thomasma 2019-10-22 21:01:34 UTC
(In reply to Julian Ragan from comment #28)
> I have narrowed it down to the following:
> If a form has more than one control and in the underlying sheet column width
> in any one column is set to different than default, then all controls on the
> form start (not always immediately) to refresh (redraw) in a continuous loop
> affecting overall performance.
> 
> Steps to reproduce the bug:
> 1.Create new sheet
> 2.Add two controls to the form
> 3.Resize a few columns on the sheet
> 
> If all columns have default width this bug will not manifest itself.
> If there is one control on the form, this bug will not manifest itself.
> 
> Reproducibility is a bit sketchy, since sometimes it starts to continuously
> refresh immediately and sometimes it takes a few seconds to catch on.

I have CALC workbook with only 1 control. It flickers so issue does occur with just 1 control
Comment 34 Xisco Faulí 2019-10-23 14:58:19 UTC
*** Bug 128107 has been marked as a duplicate of this bug. ***
Comment 35 Julian Ragan 2019-10-24 06:49:21 UTC
(In reply to Elizabeth Thomasma from comment #33)

> I have CALC workbook with only 1 control. It flickers so issue does occur
> with just 1 control

I can't reproduce it (in files created from scratch at least), without using zoom functionality (which I don't use in my workflow).
One control on a page with default zoom and non-default column width does not trigger this bug for me. 
Two or more controls and non default column width - it starts flashing after loading file, or if file is newly created, then it randomly takes up to few seconds.

However, with single control I can only reproduce the bug with the use of zoom feature.
Reproduction:
1. Create new file
2. Add one control
3. Resize one column (necessary, could not reproduce without this step)
4. Zoom out to at least 80% or zoom in to at least 110% (those values appear to be trigger points for this bug for forms with one control on them)

Can you check if you have non default zoom in your file and if yes, then check what happens with your file if you set zoom to 100%?
Comment 36 Julian Ragan 2019-10-24 07:34:18 UTC
While further testing zoom functionality I was able to once trigger this bug on a new file with default column width and one control. 

However, I was not able to reproduce with multiple attempts.
Comment 37 Xisco Faulí 2019-10-24 09:27:35 UTC
*** Bug 128368 has been marked as a duplicate of this bug. ***
Comment 38 devseppala 2019-10-24 11:24:57 UTC
I believe that I have also stumbled on this bug and it seems to be very cumbersome to trigger.

In my experience this bug triggered more by non-uniform row height than column width.  Can anyone else trigger this bug with uniform column width and non-uniform row height?

Also in my case, forcing uniform row height does fix this issue. Even if you change the height of some row afterwards.  But it is only fixed for the current zoom level. If you change the zoom level, the flickering will come back on some other zoom level. Now the bug just manifests itself on a different zoom level than previously.

Also, in some situations all of the menus and dialogs show up empty, while this bug is active.

On multiple occasions, I have been able to trigger this with just one form control, but for some reason I can not find a pattern that would work always. With two controls it is more consistent, but with two controls I have not experienced the disappearing of menus and dialogs.
Comment 39 devseppala 2019-10-24 13:05:46 UTC
Adding to previous that if you enable:
“Options > LibreOffice > View > Use OpenGL for all rendering” 

There is no flickering, but menus and dialogs show up empty. CPU use is high and GPU is 98%.
Comment 40 Julien Nabet 2019-10-24 17:26:30 UTC
Created attachment 155290 [details]
perf flamegraph

On pc Debian x86-64 with master sources updated 2 days ago, I retrieved a Flamegraph.

Perhaps it may help.
Comment 41 Julien Nabet 2019-10-29 06:34:41 UTC
Adding traces in some functions of the quoted commit, I noticed this block was repeted infinitely:
OverlayObject::getOverlayObjectPrimitive2DSequence
OverlayObject::getOverlayObjectPrimitive2DSequence
ViewObjectContact::getPrimitive2DSequence
ViewObjectContact::getGridOffset
ViewObjectContact::getPrimitive2DSequence
ViewObjectContact::getGridOffset
ViewObjectContact::getPrimitive2DSequence
ViewObjectContact::getGridOffset
Comment 42 devseppala 2019-10-30 09:43:46 UTC
When I searched the originating commit from Github:

https://github.com/LibreOffice/core/search?q=d464d505fbf6e53a38afdd3661d320fac8c760d6&type=Commits

I noticed that developer vmiklos had fixed a similar issue as this bug:

tdf#123505 svx: fix invalidation loop caused by special form control …
https://github.com/LibreOffice/core/commit/5b51aa12e8ebfa894ecfdd0c8c9004aa99e6f46d

Is there some way to ask if he could look in to this issue too. It seems very similar to the one he already worked on and is related to the same originating commit.
Comment 43 Xisco Faulí 2019-10-30 14:36:53 UTC
*** Bug 122713 has been marked as a duplicate of this bug. ***
Comment 44 Xisco Faulí 2019-10-30 14:41:42 UTC
*** Bug 125720 has been marked as a duplicate of this bug. ***
Comment 45 Armin Le Grand 2019-10-30 16:12:17 UTC
Happens when the Control is live (not edit mode) and the mapping is - due to non-linear ViewMapping in Calc - dependent on pixel sies. In these cases, ViewObjectContactOfUnoControl_Impl::positionAndZoomControl is called. That uses adjustControlGeometry_throw where

aTopLeft, aBottomRight change while
_rLogicBoundingRect does not (mostly flicker of a single pixel).

This is due to different _rViewTransformation being used, dependent on where the paint is compng from (yes, the live Controls' positioning works by lay-positioning these during paint what may lead to an invalidate in the window, but usually only *once*, except for the crude Calc non-linear ViewTransform mapping - ARGH)

Key to fix this will be to find out which tranform would be the correct one and which path uses the wrong one...

All calls emerge from a single ScGridWindow::DrawContent. Every 2nd paint triggers between two pixel value variations, this can be best seen in

ControlHolder::setPosSize

One call inside ScGridWindow::DrawContent triggers one pixel value set, another triggers the alternative one. These calls are:

    DrawRedraw( aOutputData, SC_LAYER_INTERN ); -> smaller/more left
            pContentDev->SetMapMode(aCurrentMapMode); -> bigger, more right

These do then alternate endlessly, because they invalidate different parts. Question is why these lead to different pixel position values...
Comment 46 Bernard SIAUD 2019-10-31 10:09:24 UTC
I think that's I have de same problem with this version :

Version: 6.4.0.0.alpha1
Build ID: cc57df8f942f239d29cb575ea5a7cb01405db787
Threads CPU : 4; OS : Linux 5.3; UI Render : par défaut; VCL: gtk3; 
Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Calc: threaded

I can use LibO 6.3 because the CPU up to 100% when I use my sheet with macro. LibO 6.4 have the same problem.

The file Xray have this problem.
Comment 47 Armin Le Grand 2019-10-31 18:07:01 UTC
In adjustControlGeometry_throw aViewTranslate is sometimes *not* zero, but has some values. Thi seems to be the reason for the offsets - tried to hunt down where this comes from, but hard to find - about 25 stack levels involved...
Comment 48 Armin Le Grand 2019-10-31 19:25:47 UTC
Seems to be special stuff with controls - sigh.
When breaking in svx\source\sdr\contact\objectcontactofpageview.cxx:290 in line

                    pProcessor2D->process(xPrimitiveSequence);

it can be seen that the ViewInformation2D from *this and at the processor is the same, while later in LazyControlCreationPrimitive2D::get2DDecomposition it is *different*.
This is because the processed SeqOfPrim modifies it - in VclProcessor2D::RenderTransformPrimitive2D. This means the ControlPrimitive itself contains the offset (in my local example '30' which leads to a pixel offset of 1.0889). Forcing this to zero silences the repaint.

Thus the question is: Who and why does someone create a TransformPrimitive2D? There are probably good reasons, so maybe we get a principal problem here...?
Comment 49 Armin Le Grand 2019-11-01 12:50:08 UTC
The embedding to TransformPrimitive2D is indeed created by ViewObjectContact::getPrimitive2DSequence and taking supportsGridOffsets/getGridOffset into account - what is completely corect and core element of the change.
What seems wrong OTOH is more that in ViewObjectContactOfUnoControl_Impl::positionAndZoomControl the GridOffst is *not* taken into account -> need to add that.
Made a 1st rough try in adding to _rViewTransformation, but this would add it double in the non-EndRepaint stuff. Thus the logically correct thing to do is probably to not use

                const tools::Rectangle aRect( pUnoObject->GetLogicRect() );

in ViewObjectContactOfUnoControl_Impl::positionAndZoomControl, but to get the B2DRange from the SeqOfPrim which will then correctly include the offset...
Comment 50 Armin Le Grand 2019-11-01 13:41:38 UTC
Problem is that ViewObjectContactOfUnoControl_Impl::positionAndZoomControl is used in two scenarios:
(1) During paint -> GridOffset is already part of ViewTransformation2D
(2) Other (IsVisible, getPrimSeq, ...) -> GridOffset *not* added
while (1) is coming from LazyControlCreationPrimitive2D::get2DDecomposition while (2) comes from ViewObjectContactOfUnoControl::isPrimitiveVisible.

Using m_pAntiImpl->getObjectRange() in ViewObjectContactOfUnoControl_Impl::positionAndZoomControl in both cases will not work -> in case (1) the GridOffset will be taken into account *twice*. So there are two alternatives:

(a) extend ViewObjectContactOfUnoControl_Impl::positionAndZoomControl with a flag to internally know if GridOffset is alread added
(b) add GridOffset for all usages of (2) to ViewTransformation2D

Not sure what is better, have to think about it strategically/from the underlying principle...
Comment 51 devseppala 2019-11-04 09:45:09 UTC
Very interesting to read about your bug hunt Armin, and good to see that you have made so much progress.

About your A/B solution options. Is there any performance issue to consider, how often are these called in worst case scenario. I mean checking a flag sounds potentially more slower than just systematically adding the offset.

Just my 2 cents, great work!
Comment 52 Armin Le Grand 2019-11-04 12:53:29 UTC
@devseppala: Well - the GridOffset needs to be applied in both cases, so this makes not really a difference...

From the logic I think (2) is the better option - will now do that and check if it works as intended. Keep in mind that the GridOffset stuff itself is a compromize fix for the (hard) calc probem of non-linear ViewTransformation(s) for pixel-oriented displays - I know that since I implemented it ;-)
In the long run a view-dependent solution using VOC/OC/VC in combination with primitives would be much better anyways... but thats another story ;-)
Comment 53 Armin Le Grand 2019-11-04 13:37:29 UTC
Works well, but need to update local master 1st to prepare commit ...
Comment 54 Armin Le Grand 2019-11-04 14:34:36 UTC
Proposed fix at https://gerrit.libreoffice.org/#/c/82031/
Comment 55 Commit Notification 2019-11-04 19:37:01 UTC
Armin Le Grand committed a patch related to this issue.
It has been pushed to "master":

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

tdf#121963 apply GridOffset in isPrimitiveVisible

It will be available in 6.4.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 56 Armin Le Grand 2019-11-04 19:37:39 UTC
Okay, comitted and checked by Xisco
Comment 57 Xisco Faulí 2019-11-05 10:11:28 UTC
Verified in

Version: 6.4.0.0.alpha1+
Build ID: ee909ca2c02f949605f68720c3f1eef658502749
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

@Armin, thanks for fixing this issue!!
Comment 58 devseppala 2019-11-05 10:28:10 UTC
I tested today's build:
https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/2019-11-05_05.07.09/LibreOfficeDev_6.4.0.0.alpha1_Win_x64.msi

and the fix works also for me.

Could this fix be included in the 6.3.x series too. I would consider this as quite important bug fix, and from the amount of duplicate bugs, it seems to have affected quite a few. In addition, the fix seems to be quite unintrusive and it fixes a regression introduced in this series.
Comment 59 Julian Ragan 2019-11-05 10:54:34 UTC
I confirm fixed on 

Wersja: 6.4.0.0.alpha1+ (x64)
Build ID: 16dd2d153475265e9bdf9b8e736dca0b7b5b20f9
Wątki CPU: 8; OS:Windows 6.1 Service Pack 1 Build 7601; UI render:domyślny; VCL: win; 
Ustawienia regionalne: pl-PL (pl_PL); UI-Language: pl-PL
Calc: CL
Comment 60 Commit Notification 2019-11-05 14:02:49 UTC
Armin Le Grand committed a patch related to this issue.
It has been pushed to "libreoffice-6-3":

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

tdf#121963 apply GridOffset in isPrimitiveVisible

It will be available in 6.3.4.

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 61 Oliver Brinzing 2019-11-09 15:17:31 UTC
*** Bug 128685 has been marked as a duplicate of this bug. ***
Comment 62 Kino 2019-12-02 13:35:10 UTC
I have just installed LO 6.3.3 and the problem is NOT fixed.
I have two macro buttons and one of them "vibrates" as if being constantly pressed.
Comment 63 Xisco Faulí 2019-12-02 13:36:39 UTC
(In reply to Kino from comment #62)
> I have just installed LO 6.3.3 and the problem is NOT fixed.
> I have two macro buttons and one of them "vibrates" as if being constantly
> pressed.

it's fixed in LibreOffice 6.3.4 which is going to be released next week