Description: GIF animation speed drops with spinning beachball Steps to Reproduce: 1. Open attachment 159163 [details] 2. Go to sheet 2. Drag the gif to some different spot 3. Switch to sheet 5 4. Minimize the Window 5. Restore the window by click LibreOffice icon in the dock 6. Drag the gif on sheet 5 7. Switch to sheet 2 and hoover over the gif 8. Switch back forward between 2 - 5 if there is no lag Actual Results: Massive slowdown; dialogs become slow Expected Results: Normal speed Reproducible: Always User Profile Reset: No Additional Info: Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7fddf33f70b5e496ca7e3936a845d47b9deca027 CPU threads: 8; OS: macOS 14.7.4; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Created attachment 201265 [details] Xcode Instruments Performance trace
Thank you for reporting the bug. I can confirm slowdown of the GIF animation is present in both versions of LibreOffice listed below. Notable is that in v25.8, I don't get the beachball, I get the hand/glove icon but the slowdown is present and very noticable. Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 84da1f50ca8261129909901c2ff72adb9c67510a CPU threads: 8; OS: macOS 15.2; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Version: 25.2.3.2 (X86_64) / LibreOffice Community Build ID: bbb074479178df812d175f709636b368952c2ce3 CPU threads: 8; OS: macOS 15.2; UI render: Skia/Raster; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
I cannot reproduce this bug in my local master build on Mac Silicon. Maybe it is only limited to Mac Intel?: Version: 26.2.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: a25172b81142df86b7c1854edbeb885d63bf0182 CPU threads: 8; OS: macOS 15.5; UI render: Skia/Raster; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded
Not specific to macOS 1. Open attachment 159163 [details] 2. Go to sheet 2 3. Copy the GIF 4. New Impress sheet (don't close the source) 5. Paste the GIF (2x) 6. Move on of the gives (to prevent to be stacked) 7. Press Play presentation.. Wait (frame drop does occur within 10 seconds). 8. If not press ESC.. Framedrop should occur now SideNote: I increased the ImageCacheSize to 512 MB on my Windows machine with low resolution screen
Argh, it's the swapOut GraphicFilter::readGIF GraphicFilter::ImportGraphic GfxLink::LoadNative ImpGraphic::swapOut ImpGraphic::swapOut ImpGraphic::getSwapFileStream A) I increased the ImageCacheSize for Skia to 1024 MB, however keeps swapping B) I increased the GraphicMemoryLimit from 300 MB to 1024, problem solved, even with ImageCacheSize set to 64 MB
Some background regarding the GraphicMemoryLimit https://git.libreoffice.org/core/+/7b355669c6ddeab2e6cec692d6afdff41c61d0fb%5E%21
(In reply to Telesto from comment #5) > A) I increased the ImageCacheSize for Skia to 1024 MB, however keeps swapping > B) I increased the GraphicMemoryLimit from 300 MB to 1024, problem solved, > even with ImageCacheSize set to 64 MB OK. I can now reproduce this bug using the steps in comment #4. Also, the bug disappears when I set the GraphicMemoryLimit export preference to 1024000000: Version: 26.2.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: a25172b81142df86b7c1854edbeb885d63bf0182 CPU threads: 8; OS: macOS 15.5; UI render: Skia/Raster; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded
(In reply to Patrick (volunteer) from comment #7) > OK. I can now reproduce this bug using the steps in comment #4. Also, the > bug disappears when I set the GraphicMemoryLimit export preference to > 1024000000: I wonder if using the solution for tdf#166007 could work with the image cache that GraphicsMemoryLimit controls: https://gerrit.libreoffice.org/c/core/+/187790 I'll see if can adapt the above code so that the image cache can temporarily exceed the GraphicsMemoryLimit like the above patch does for the Skia image cache. I'll post again when I have any news.
(In reply to Patrick (volunteer) from comment #8) > I wonder if using the solution for tdf#166007 could work with the image > cache that GraphicsMemoryLimit controls: Correction: I should have written "the solution for tdf#166994". Anyway, apparently the GraphicsMemoryLimit image cache already has similar code to my fix for tdf#166994. The current code uses a minimum time that an image is supposed to remain in the cache which the default is 10 seconds. The fix for tdf#166994 only needed 5 seconds so I think 10 seconds should be enough so I put some printf's in the cache code and found that the bug occurs when the first frame of an animation is removed from the cache. After that, all of the other frames in an animation are never readded to the cache. AFAICT, with the following debug patch, once the bug occurs, I see a blizzard of "unregister" (i.e. remove from the cache) calls interspersed with an occasional "register" (i.e. add to the cache). Also, in those blizzard of "unregister" calls, the image being removed does not exist in the cache. So my current theory is that once the bug occurs, every frame is being swapped in, drawn, and then swapped out and this repeated swapping in and out is what is slowing the animations: diff --git a/vcl/source/graphic/Manager.cxx b/vcl/source/graphic/Manager.cxx index bafa2711cbff..3db528153d52 100644 --- a/vcl/source/graphic/Manager.cxx +++ b/vcl/source/graphic/Manager.cxx @@ -87,6 +87,7 @@ void MemoryManager::registerObject(MemoryManaged* pMemoryManaged) assert(aGuard.owns_lock() && aGuard.mutex() == &maMutex); // coverity[missing_lock: FALSE] - as above assert mnTotalSize += pMemoryManaged->getCurrentSizeInBytes(); +fprintf(stderr, "register: %p\n", pMemoryManaged); maObjectList.insert(pMemoryManaged); checkStartReduceTimer(); } @@ -95,6 +96,8 @@ void MemoryManager::unregisterObject(MemoryManaged* pMemoryManaged) { std::unique_lock aGuard(maMutex); mnTotalSize -= pMemoryManaged->getCurrentSizeInBytes(); +auto it = maObjectList.find(pMemoryManaged); +fprintf(stderr, "unregister: %p %i\n", pMemoryManaged, it == maObjectList.end() ? 1 : 0); maObjectList.erase(pMemoryManaged); checkStartReduceTimer(); }
OK. I have gotten this bug to stop using the following patch: https://gerrit.libreoffice.org/c/core/+/187836 However, I don't think it is a real fix as it causes the Instruments application to show a 0.5 GB increase in memory usage after I do the steps in comment #4 and close all documents without saving. That's not good at all but what I did notice was that after the animation is removed from the cache, the animation repeatedly swaps out and then swaps the image back into memory.
(In reply to Patrick (volunteer) from comment #10) > That's not good at all but what I did notice was that after the animation is > removed from the cache, the animation repeatedly swaps out and then swaps > the image back into memory. Update: I found that the animation only gets removed from the graphics cache once. After that, the bug occurs. So, AFAICT it appears that the problem is not the graphics cache but, instead, is the failure of an animation to get readd its frames to the graphics cache after the first removal. More debugging is needed. I'll post more when I have more data.
I have submitted a fix for this bug: https://gerrit.libreoffice.org/c/core/+/187836 It still needs to be reviewed but what surprised me was that, with my fix, doing the steps in comment #4 only adds 2 more images to the GraphicMemoryLimit cache than without the fix.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/eed9c590db8e94ddc5cc20bc25a779284c9b9249 tdf#167007 Add animated graphic to cache when prepared It will be available in 26.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.
My fix has been committed and the fix should be in tomorrow's (23 July 2025) nightly master builds: https://dev-builds.libreoffice.org/daily/master/current.html Note for macOS testers: the nightly master build installer does not overwrite any LibreOffice official versions. Instead, it will be installed as a separate application called "LibreOfficeDev" in the /Applications folder. Because this is a "test" build, you will need to do the following steps before you launch the LibreOfficeDev application: 1. Go to the Finder and navigate to the /Applications/Utilities folder 2. Launch the "Terminal" application 3. Paste the following command in the Terminal application window and press the Return key to execute the command: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app
Works nicely Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7f4868348c14b305fcd75744e1e3544d0d3a5d61 CPU threads: 8; OS: macOS 14.7.4; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/4bbef581d68b391a4de57cc36c85775635f324d6 tdf#167007 Add animated graphic to cache when prepared It will be available in 25.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.