Description: Freeze (beachball) when hoovering with mouse above an animating gif (macOS) Steps to Reproduce: 1. Open Impress 2. Insert attachment 186976 [details] 3. Hoover with the mouse above the image/gif and.or open presentation mode Actual Results: The red dot does move across the chart in slow motion and spinning beachballs. Expected Results: Being able to edit the slide Reproducible: Always User Profile Reset: No Additional Info: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5682e1d4145c26fc8021879df0543d5aeacf9c83 CPU threads: 8; OS: macOS 13.4.1; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Looking for a service with information about tesofensine? The information about side effects of tesofensine at https://valhallavitality.com/blog/side-effects-of-tesofensine-understanding-the-adverse-effects-of-this-novel-drug was very helpful. It was especially important to learn about possible changes in sleep. The site provided an accurate and detailed description, helping me prepare for these effects.
I have always been a fan of chiropractic care. I believe it is a great way to keep your spine healthy. When I heard about the chairs from https://corechair.com/unveiling-the-magic-of-corechair-the-revolutionary-chiropractic-solution-for-back-pain/, I was immediately interested. This chair combines chiropractic principles with modern design. I have been using the CoreChair for several months now and I am very pleased with the results. My back pain is gone and my posture has improved. I feel more energetic and productive. I believe that CoreChair is the best chair for those who want to get rid of back pain and improve their overall health.
Je voulais partager mon expérience récente avec la réparation de mon lave-vaisselle. Il y a quelques jours, il a soudainement cessé de fonctionner, et au lieu de paniquer et d'appeler un réparateur, j'ai décidé de prendre les choses en main. Après quelques recherches en ligne et quelques vidéos tutorielles, j'ai identifié le problème et j'ai pu le réparer moi-même ! C'était vraiment gratifiant de pouvoir résoudre le problème sans dépenser une fortune en réparations professionnelles. Donc, si votre lave-vaisselle rencontre des problèmes, n'ayez pas peur de faire quelques recherches et de tenter de le réparer vous-même ! https://serviceservotech.com/fr/reparation-electromenagers/reparation-lave-vaisselle/
On both Windows and Linux, also reproduced the slowdown on hovering and moving the cursor off the gif. Occasionally, I get a more serious slowdown or a complete freeze, but unsure how to reproduce reliably. Version: 24.2.1.1 (X86_64) / LibreOffice Community Build ID: 359ef544e625d2ffbfced462ab37bd593ca85fa7 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 4; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded I also reproduce a slight slowdown in LO 6.0, so that issue has been around for a while. But It has gotten worse along the way. Is the issue in macOS a clear regression when comparing to 7.6, Telesto?
(In reply to Stéphane Guillou (stragu) from comment #4) > Is the issue in macOS a clear regression when comparing to 7.6, Telesto? It's workable but slow with Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1cfeb4bd8ce7f7727a81136bd3e2d6ebea976895 CPU threads: 8; OS: Mac OS X 14.3; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded It's essentially unworkable with Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 907c5d684daeb055183abb9175405c6d68fb1f49 CPU threads: 8; OS: macOS 14.3; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded so from bad to worse. A bibisect would be possible, i guess.
I wonder if the fixes for bug 153162 have an effect on the slideshow perf.
Doesn't seem bad in slideshow mode. In edit mode, there is a pause and CPU use getting higher when opening and closing a dialog. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9b41d33a00763bebd5fc70787052222d35a98a52 CPU threads: 2; OS: Windows 11 (10.0 build 22621); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
@Patrick This bug is actually part of bigger issue (OS independent) with animating gifs (bug 104878; bit more in detail bug 104878 comment 42). The difference: slowdown starts with moving mouse cursor above the animating image with (Windows). Whereas having the mouse cursor simply above the animating gif causing spinning beach balls on macOS: So it's even hard to move the mouse away from the image There are no slowdowns in presentation mode. Bottom line: creating presentations with GIFS on MacOS is terrible. It's still very bad on others OSes Your debugging skills are good and the perseverance to getting it right too :-). It's only a poke. If you say: not my cup of tea, also fine.
(In reply to Telesto from comment #8) > @Patrick > This bug is actually part of bigger issue (OS independent) with animating > gifs (bug 104878; bit more in detail bug 104878 comment 42). The difference: > slowdown starts with moving mouse cursor above the animating image with > (Windows). Whereas having the mouse cursor simply above the animating gif > causing spinning beach balls on macOS: So it's even hard to move the mouse > away from the image I can definitely reproduce this bug in my local master build. But surprisingly, I see no beachballs when using Skia/Metal. With Skia/Metal, the only symtom of this bug is that the would stop when I moved the mouse. With the mouse not moving and sitting on top of the .gif image, the animation speed seemed normal. When using Skia/Raster, I see constant beachballs like you described. With Skia disabled, the frequency of beachballs was somewhere between Skia/Metal and Skia/Raster. I will see if I can use the CPU Profiler tool in the Instruments application to find out what the LibreOffice code is doing during the beachballs when running Skia/Raster.
Created attachment 195052 [details] Snapshot of CPU Profile in Instruments application when using Skia/Raster
(In reply to Patrick Luby (volunteer) from comment #10) > Created attachment 195052 [details] > Snapshot of CPU Profile in Instruments application when using Skia/Raster In the CPU Profile I ran, the 2 selected lines were using 2/3rds of total CPU usage. So I commented out FuDraw::ForcePointer() using the following debug patch and that made Skia/Raster behave very closely to Skia/Metal i.e. only a brief pause when moving the mouse and no pause when not moving the mouse. I suspect that even without the FuDraw::ForcePointer() code, there are still other places using excessive CPU, but FuDraw::ForcePointer() appears to be the biggest contributor to this bug so I'll see if I can find a fix for that first: diff --git a/sd/source/ui/func/fudraw.cxx b/sd/source/ui/func/fudraw.cxx index 3e36d5d78f76..cf2bff5e6488 100644 --- a/sd/source/ui/func/fudraw.cxx +++ b/sd/source/ui/func/fudraw.cxx @@ -450,6 +450,8 @@ void FuDraw::Activate() */ void FuDraw::ForcePointer(const MouseEvent* pMEvt) { +(void)pMEvt; +#if 0 Point aPnt; sal_uInt16 nModifier = 0; bool bLeftDown = false; @@ -574,6 +576,7 @@ void FuDraw::ForcePointer(const MouseEvent* pMEvt) mpWindow->SetPointer(mpView->GetPreferredPointer( aPnt, mpWindow->GetOutDev(), nModifier, bLeftDown)); } +#endif } /**
So I have narrowed down where the bottleneck is: it is in the ViewObjectContactPrimitiveHit() function. In the attached CPU Profile, I noticed that ViewObjectContactPrimitiveHit() actually forces a redraw of the image which seems odd to me when the function name implies that we are just "hit testing" (i.e. finding which visual object is at a specific location). Skipping ViewObjectContactPrimitiveHit() in the following debug patch eliminates the forced redrawing and I see no longer see any pause in the image animation with Skia/Raster, even when continuously moving the mouse within the image. So, next step is to figure out how to get the code to not redraw the image during a hit testing: diff --git a/svx/source/svdraw/sdrhittesthelper.cxx b/svx/source/svdraw/sdrhittesthelper.cxx index 9dc3b9118f07..45feaafac46f 100644 --- a/svx/source/svdraw/sdrhittesthelper.cxx +++ b/svx/source/svdraw/sdrhittesthelper.cxx @@ -77,10 +77,15 @@ SdrObject* SdrObjectPrimitiveHit( const sdr::contact::ViewObjectContact& rVOC = rObject.GetViewContact().GetViewObjectContact( rSdrPageView.GetPageWindow(0)->GetObjectContact()); +(void)aHitPosition; +(void)rVOC; +(void)pHitContainer; +#if 0 if(ViewObjectContactPrimitiveHit(rVOC, aHitPosition, rHitTolerance, bTextOnly, pHitContainer)) { pResult = const_cast< SdrObject* >(&rObject); } +#endif } } }
Thanks for looking into this and all the updates. Hope you can find a way! Armin Le Grand might have some idea's too, if you got stuck.
(In reply to Telesto from comment #13) > Thanks for looking into this and all the updates. Hope you can find a way! > Armin Le Grand might have some idea's too, if you got stuck. Sorry, but I don't know how to unpack this. Seems you want me to lean on (i.e. guilt) someone I've never met to work on your bug. No thanks. Typical "all hands on deck for my bug" behavior. What really catches my eye is that you reported this bug 6 months ago and during all of that time, you could've run an Instruments CPU Profile. I still remember the shit I went through to enable connecting to LibreOffice to Instruments over a year ago. Yet, zero interest in using Apple's amazing leak and CPU usage tool. Six month and no one has bothered to fire up the Instruments application. But now I need to run around and ask for everyone's input because apparently I'm not moving fast enough. I'll fix it when I fix it.
(In reply to Patrick Luby (volunteer) from comment #14) > What really catches my eye is that you reported this bug 6 months ago and > during all of that time, you could've run an Instruments CPU Profile. I > still remember the shit I went through to enable connecting to LibreOffice > to Instruments over a year ago. Yet, zero interest in using Apple's amazing > leak and CPU usage tool. Seriously, you should now expect me to ask for a screen snapshot of the Instruments application in the future when you cc: me on a bug.
(In reply to Patrick Luby (volunteer) from comment #14) > Sorry, but I don't know how to unpack this. Seems you want me to lean on > (i.e. guilt) someone I've never met to work on your bug. No thanks. Typical > "all hands on deck for my bug" behavior. Well I might not have realized how this could be perceived/interpreted. Is surely not my idea to force you to work with someone else or to guilt someone else also working on this. Most developers have so expertise area. This is somewhat is his area. So if you need help...; which is quite suggestive and premature. I shouldn't have kept my mouth shut, IMHO. Dev e-mail list probably better place anyhow. > What really catches my eye is that you reported this bug 6 months ago and > during all of that time, you could've run an Instruments CPU Profile. I > still remember the shit I went through to enable connecting to LibreOffice > to Instruments over a year ago. Yet, zero interest in using Apple's amazing > leak and CPU usage tool. > Six month and no one has bothered to fire up the Instruments application. > But now I need to run around and ask for everyone's input because apparently > I'm not moving fast enough. I do use the Instruments application once in a while. I'm grateful you a enable connecting to LibreOffice. However it feels bit as random posting screenshots if you not 100% convinced about what you're doing. Drill down the list until until the last item in the stack with high CPU time spend It also a kind of a snapshots, which can age very quickly. It feels bit pointless task if nobody takes a look. But if you prefer so to have instruments sreenshot before CC, I will do. > I'll fix it when I fix it. There is no rush; the bug is present for years.
I have now determined that this is a cross-platform bug. The only reason that it is seen on macOS is because, with a Retina display, all LibreOffice offscreen drawing surfaces hold 4 subpixels for every pixel. By running from the Terminal with the following environment variable, the problem disappears and, with Skia/Raster, I only see a slight pause in the animation when moving the mouse over the .gif image. The real problem is in the drawinglayer module. From the following debug patch, it is clear to me that drawinglayer::processor2d::HitTestProcessor2D::process() actually redraws the entire image object on every single mouse event (click or move) which, seems very strange when the code in the following debug patch is just trying to do a hit test. I don't have much experience with the drawinglayer module and time is very limited for me so I won't be able to fix this bug: diff --git a/svx/source/svdraw/sdrhittesthelper.cxx b/svx/source/svdraw/sdrhittesthelper.cxx index 9dc3b9118f07..57680d02f27c 100644 --- a/svx/source/svdraw/sdrhittesthelper.cxx +++ b/svx/source/svdraw/sdrhittesthelper.cxx @@ -152,7 +152,7 @@ bool ViewObjectContactPrimitiveHit( aHitTestProcessor2D.collectHitStack(pHitContainer != nullptr); // feed it with the primitives - aHitTestProcessor2D.process(aSequence); + // aHitTestProcessor2D.process(aSequence); // deliver result if (aHitTestProcessor2D.getHit())
Interesting. If I insert this image into Impress, it does not animate at all in edit mode, only when running the presentation. I wonder why that is? I do have "Allow animates images" to true in my preferences.
(In reply to Noel Grandin from comment #18) > Interesting. If I insert this image into Impress, it does not animate at all > in edit mode, only when running the presentation. > I wonder why that is? > I do have "Allow animates images" to true in my preferences. Well I have the same issue on Windows, but nobody could reproduce it. Bug 160646
fix for this is here: https://gerrit.libreoffice.org/c/core/+/170587
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b40ecb9bff633ad6f301d8a8bf169a94b52ccbb2 tdf#158397 freeze hovering mouse above animating gif It will be available in 25.2.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.
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/7df76cda53dfdb60dab1e2189cafc86d9a30461a tdf#158397 freeze hovering mouse above animating gif It will be available in 24.8.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.