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:
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 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
*** Bug 122083 has been marked as a duplicate of this bug. ***
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
*** Bug 122644 has been marked as a duplicate of this bug. ***
REPRODUCIBLE with Version: 6.3.0.0.alpha0+ Build ID: 2e3b0c5d42d60d46cd9f8b8eda9424b095c63418; Windows 6.1 and own sample document with form controls
The mentioned commit also breaks the mouse wheel zooming if there is a button on the spreadsheet. Increasing severity towards 6.3 release
*** Bug 126558 has been marked as a duplicate of this bug. ***
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:
*** Bug 126778 has been marked as a duplicate of this bug. ***
*** Bug 126845 has been marked as a duplicate of this bug. ***
*** Bug 126987 has been marked as a duplicate of this bug. ***
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
*** Bug 127155 has been marked as a duplicate of this bug. ***
*** Bug 127352 has been marked as a duplicate of this bug. ***
In calc Side bar, cell appearance - > cell border line style[ on adding any cell border enable it] flickering continuously.
*** Bug 127444 has been marked as a duplicate of this bug. ***
*** Bug 127503 has been marked as a duplicate of this bug. ***
*** Bug 127563 has been marked as a duplicate of this bug. ***
*** Bug 127067 has been marked as a duplicate of this bug. ***
*** Bug 127636 has been marked as a duplicate of this bug. ***
*** Bug 127828 has been marked as a duplicate of this bug. ***
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 ;-)
*** Bug 127842 has been marked as a duplicate of this bug. ***
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!
*** Bug 128093 has been marked as a duplicate of this bug. ***
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
Simple Questions / Feedback / Observations (please don't take offence): * You have a stable version (6.2), so what is the purpose of something like the 6.3 version, with multiple releases. I can understand alpha/beta versions being available whilst bugs/design issues are being addressed, but when you remove those statuses and give it what appears to be a "released" version nomenclature, then user expectation changes accordingly. * This problem, which at first sight seems to be quite serious for those afflicted by it, has been identified around 10 months ago. Given the previous point, not having any feedback regarding ETA (or even if it is being looked at) is disturbing. As I said, purely from a user's perspective, ver 6.3 looks like a production version of LO. And therefore, I would also have an expectation about having to revert as a result of inactivity, losing as a result, the slew of excellent enhancements present in 6.3 regards, Steve
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.
*** Bug 128147 has been marked as a duplicate of this bug. ***
*** Bug 128151 has been marked as a duplicate of this bug. ***
(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
*** Bug 128326 has been marked as a duplicate of this bug. ***
(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
*** Bug 128107 has been marked as a duplicate of this bug. ***
(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%?
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.
*** Bug 128368 has been marked as a duplicate of this bug. ***
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.
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%.
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.
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
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.
*** Bug 122713 has been marked as a duplicate of this bug. ***
*** Bug 125720 has been marked as a duplicate of this bug. ***
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...
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.
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...
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...?
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...
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...
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!
@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 ;-)
Works well, but need to update local master 1st to prepare commit ...
Proposed fix at https://gerrit.libreoffice.org/#/c/82031/
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.
Okay, comitted and checked by Xisco
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!!
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.
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
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.
*** Bug 128685 has been marked as a duplicate of this bug. ***
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.
(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
*** Bug 129285 has been marked as a duplicate of this bug. ***
*** Bug 129718 has been marked as a duplicate of this bug. ***
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0d3d40b2668c879d8deb3b39f7c243e22b70bdcb tdf#121963: Add unittest It will be available in 7.0.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.
Until prompted by the status change (mentioning 6.3.4) on this I hadn't checked it, expecting to have to wait for 6.4 on ubuntu. I can confirm it's fixed in Version: 6.3.5.1 Build ID: 1:6.3.5~rc1-0ubuntu0.19.10.1~lo1 CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: x11; Locale: en-GB (en_GB.UTF-8); UI-Language: en-GB Calc: threaded
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2f9b7f4d7d35d0e2d85132792f8c74c54f05d6c1 tdf#121963: Add unittest (part 2) It will be available in 7.0.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.