Description: Mac OS Sonoma M1 Working with a multipage Draw document, e.g. 8 pages. Each page contains 2 inserted image files. It doesn't seem to matter which file type. I my case, the files are either all jpg, all png, or all tiff. The file sizes can be anything from a few hundred kb to several Mb. After each image insertion, I generally centre the image horizontally on the page. Each page also contains a Figure number textbox, under the image, eg "Fig. 2" I save the Draw file after each image insertion. The file is saved, but then systematically freezes for a while and the UI is unresponsive to clicks, scrolls or other mouse events. Switching window contexts to another desktop virtual screen and back to the one on which LO is displayed, seems to bring LO back to life more quickly than just waiting, but it is not immediate even then. This makes working with Draw nearly impossible. Current version is 7.6.6.3, but the problem has been present at least since 7.6.3. Safe mode changes nothing. Steps to Reproduce: 1. Open a new Draw document. 2. Insert an image file of decent size, from between several hundred kb to several tens of Mb. 3. After each image insertion, save the Draw file. 4. Repeat the process so that there are 2 images per Draw page, and keep adding successive new pages to the file, each with its own images inserted. 5. Save after each insertion. 6. Notice how Draw becomes unresponsive to mouse interaction or keyboard interaction for a significant period of time (several seconds) 3. Actual Results: See description Expected Results: Freeze on save, UI unresponsive. Reproducible: Always User Profile Reset: Yes Additional Info: Save and return UI responsiveness to user immediately. LO7663, but also 7642 and 763.
Alex, do you still see this in 24.2? And is it a regression from early 7.6? Or 7.5? I just tested on Linux with a file containing 8 pages with 2 photos each, totalling 55 mb, no slow down. Version: 7.6.7.2 (X86_64) / LibreOffice Community Build ID: dd47e4b30cb7dab30588d6c79c651f218165e3c5 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
@Stephane: I'll have a chance to try with 24.2 this week as I've got some more patent drawings to prepare. I have a sneaky suspicion that it is specifically a macos problem though.
[Automated Action] NeedInfo-To-Unconfirmed
Unfortunately, this is still happening with 24.2.x
When I'm back in the office, I'll try and get a screen capture video to show the behaviour.
No issue on a Intel Mac Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 151d997365f7bf271d63af535d29a9c3439c6d46 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
@Patrick Could this be some arm specific issue?
(In reply to Telesto from comment #7) > @Patrick > Could this be some arm specific issue? I cannot reproduce this with my local master build. I inserted a total of 16 .jpeg images that were each roughly 3 MB in size. Even when saving after inserting the last image, saving took no more than a second or two and the mouse was immediately responsive after saving ended: Version: 25.2.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: ecb0d08e3cfcad18006c0090b9b5b19c1c0f7b9c CPU threads: 8; OS: macOS 14.5; UI render: Skia/Raster; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded @Alex is it possible to obtain a sample using the Activity Monitor application during a temporary hang?
The problem appears to have gone away with 24.2.5 so marking as WFM.