Description: After using 7.2.0.0 alpha non-stop for about an hour, menus take time to render, pictures take a while to replace, and the whole interface seems to slow down. My apologies for not providing a precise set of repeatable steps to follow, it's just something I noticed eventually. After clearing the option "Force Skia Software Rendering" the problem hasn't returned, and I've been working that way now for at least 30 minutes. Steps to Reproduce: 1. Launch MS WINDOWS LO Draw 2. Edit text, insert pictures, export to PNG, for about an hour Actual Results: Program gets slower and slower to respond Expected Results: Should not slow down Reproducible: Always User Profile Reset: No Additional Info: Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 396c2ad2daad6fe6a11703d0ae1593929834afe2 CPU threads: 8; OS: Windows 10.0 Build 21301; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
Don't know at all whether it matters, but my nVidia graphics driver is 461.40.
I'm closing this because the problem seems to be (major guess on my part) more a case of being in Draw and repeatedly using the image replace shortcut menu (I audition a ton of PNG photographs next to each other in pamphlets) and after about 90 minutes or so I must quit LO because it's getting slower and slower and eventually becomes unusable, which is why I wrote this bug, but it's not necessarily a Skia problem. PNG images range from about 500k to 1M each. It's ridiculous to ask someone to spend 90 minutes repeatedly using the image replace feature to test, so I'm closing this.
(In reply to mwtjunkmail from comment #2) > I'm closing this because the problem seems to be (major guess on my part) > more a case of being in Draw and repeatedly using the image replace shortcut > menu (I audition a ton of PNG photographs next to each other in pamphlets) > and after about 90 minutes or so I must quit LO because it's getting slower > and slower and eventually becomes unusable, which is why I wrote this bug, > but it's not necessarily a Skia problem. PNG images range from about 500k to > 1M each. > > It's ridiculous to ask someone to spend 90 minutes repeatedly using the > image replace feature to test, so I'm closing this. Hmm, I would assume the number of times matters.. And maybe also the file size.. So if take some idiotic high res NASA picture I might go faster. The replacement can be scripted (macro or so). Which would take the fuzz about it doing manually. I doesn't sound really surprising it's leaking to me. Image handling as such likely leaking somewhere. Pretty convinced about that.. And you should be able to work a day without close and restart (my ideal/'target') without equipping all ram. So it's more about optimizing the steps
If we focus on Skia here, would it be possible to give a try to daily master (see https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/current/) + last graphic driver (see https://wiki.documentfoundation.org/QA/FirstSteps#Graphics-related_issues_.28Skia.29 for more info)? If leak is reproduced, please attach an example image. (unless you mean it happens with any png image?)
(In reply to Julien Nabet from comment #4) > If we focus on Skia here, would it be possible to give a try to daily master > (see > https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/current/ > ) + last graphic driver (see > https://wiki.documentfoundation.org/QA/FirstSteps#Graphics-related_issues_. > 28Skia.29 for more info)? > If leak is reproduced, please attach an example image. (unless you mean it > happens with any png image?) Thanks for checking in on this bug. I download the daily master about once a week (not every daily build is much of a compelling download, like today's is nothing but typo fixes) but I'm currently downloading the 2021.10.10 daily master and can check later. I use a variety of PNGs. Most are portrait images 528 x 738 pixels at 32bit depth, but I also create PNGs with dimensions that fit the Sims4 geometry meshes I use to make Sims4 mods, which vary in size and depth. I notice the slowdown most frequently after an hour or so of auditioning the 528 x 738 PNGs, constantly using the in-situ Replace feature while making up my ever-loving mind which pictures I want to use. It doesn't magically happen with just a few replacements. I'll try to craft a situation where I can identify the slow down faster and supply some sample images as well as the conditions that I use to export them (some, like the Sims4 mods, require transparency, and some have master pages, which aren't supported -- don't appear at all -- on PNGs exported with transparency). It may be some time before I can supply anything.
(In reply to xordevoreaux from comment #5) Hypothesis: this could be related to Image replacement functionality; not Skia as such. And maybe large images speeding up the process?
Created attachment 175620 [details] Example file 1. Download the attached file 1a. Open process manager 2. Insert in Draw 3. Save -> Export to PNG without compression 4. Replace the present image with the PNG 5. Repeat the replace.. multiple times.. memory usage will go up pretty quick (which eventually cause swapping). This happens more prominently with PNG. Tried replacing in JPG format, but not much to be seen
Created attachment 175622 [details] screenshots showing Windows memory usage A compilation of several screenshots of Windows Task Manager showing memory allotment after 0, 20, 40, 60, 80, and 100 replacements of Telesto's sample PNG file in a brand new LO Draw document created with: Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 21b2c6b7d8f4661dcbd40df4f8b9126d331cbd7f CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL with the document's page dimensions set to 42.66″ x 21.33″ inches, which produces an exported PNG 4096 x 2048 pixels (which is proportional to the dimensions of Telesto's sample image). Shown in this attachment, notice that the memory consumption progressed from 447.3MB starting with 0 replacements ending at 2,178.0MB after 100 replacements, resulting in an almost five-fold increase (4.8 times) the memory consumption in less than 10 minutes. The only delay during testing was time taken to screenshot Task Manager. Other than that, it was just a rapid image replacement, one after another, saving after every 20 replacements. While this attachment shows the memory leak created using the image replacement function, I did NOT see a notable degradation in performance as far as speed (saving the document) goes. That tells me that the speed degradation may be a problem with either the brevity of this test, in that it doesn't approach my typical real-world usage of the program in both number of replacements (think 30+ pages in a Draw document, each having 2 or images, and me spending lots of time replacing them while I audition images for the best possible composition of the final image) or the actual number of replacements over time -- or --- just to throw a wrench into things, in a real-world situation I'm also heavily editing text captions as I pull in each picture (so the caption matches the content of the image). Regardless of the reason for the degradation of speed over time, usually manifesting itself in how long it takes the document to save (despite that the actual number of pages / images the document contains might not have changed throughout the course of working with the document) this test at least serves to demonstrate the memory leak.
Also note that in addition to the dimensions of the document cited above, there were no page margins and PNGs were exported without the transparency option set. Thanks, Telesto, for supplying the test image.
I also just now sat here and watched Task Manager while I did absolutely nothing but save the document over and over. Each save resulted in a 1 to 2MB increase in memory allotment, going from 386MB upon opening the document to 427MB used after 20 saves, so while saving might contribute in some minor way to the memory leak, saving so doesn't even approach the doubling in memory usage after 20 image replacements.
We can also probably change the title of this bug because I was not forcing Skia software usage during any of today's testing.
(In reply to Telesto from comment #7) > Created attachment 175620 [details] > Example file > > 1. Download the attached file > 1a. Open process manager > 2. Insert in Draw > 3. Save -> Export to PNG without compression > 4. Replace the present image with the PNG > 5. Repeat the replace.. multiple times.. memory usage will go up pretty > quick (which eventually cause swapping). This happens more prominently with > PNG. Tried replacing in JPG format, but not much to be seen Is it important to begin with the jpg=>png conversion to show the memleak? I mean, can't we reproduce this starting with a png file that we insert and replace each time?
(In reply to Julien Nabet from comment #12) > (In reply to Telesto from comment #7) > > Created attachment 175620 [details] > > Example file > > > > 1. Download the attached file > > 1a. Open process manager > > 2. Insert in Draw > > 3. Save -> Export to PNG without compression > > 4. Replace the present image with the PNG > > 5. Repeat the replace.. multiple times.. memory usage will go up pretty > > quick (which eventually cause swapping). This happens more prominently with > > PNG. Tried replacing in JPG format, but not much to be seen > > Is it important to begin with the jpg=>png conversion to show the memleak? I > mean, can't we reproduce this starting with a png file that we insert and > replace each time? Didn't even realize his file was a JPG. I just now converted Telesto's supplied JPG file to a 32-bit PNG file. Whopping 127 MB. I'll try testing using one of my smaller PNGs that I use and see if there's an appreciable memory leak in x many replacements.
Yep using small png to show memleak could be useful because tools like Valgrind are very slow. So with an image of 127MB, it's too long.
(In reply to Julien Nabet from comment #14) > Yep using small png to show memleak could be useful because tools like > Valgrind are very slow. So with an image of 127MB, it's too long. 40 replacements of a 528 x 738 32-bit PNG file (one of my standards) went from 215MB initial memory allotment to 355MB, 1.6 times initial, and additional memory is consumed per save at about the same rate (1-2MB per save) as the previous test. So the leak is there, possibly two, but I have 32GB of ram in this box, so the other issue -- whatever is slowing me down over time -- I don't believe is this leak. I'm prepared to speculate what's causing the performance degradation over time, but haven't tested my idea and I don't want to distract from this bug report.
Created attachment 175626 [details] test file My PNG test file.
Created attachment 175633 [details] Example file (7 MB PNG) Replacing the 127 MB file
On pc Debian x86-64 with master sources updated today, I tried to get a Valgrind trace with --leak-check=full but I don't see anything wrong. Now I'm not a Valgrind expert. I suppose there are other tools on Linux but don't have the patience to test them. I think there should be a standard tool with a quick and simple tuto, after all it's just C++, not an exotic language. Anyway, I can't help here=>uncc myself.
(In reply to Julien Nabet from comment #18) > On pc Debian x86-64 with master sources updated today, I tried to get a > Valgrind trace with --leak-check=full but I don't see anything wrong. Now > I'm not a Valgrind expert. I suppose there are other tools on Linux but > don't have the patience to test them. I think there should be a standard > tool with a quick and simple tuto, after all it's just C++, not an exotic > language. > Anyway, I can't help here=>uncc myself. May not be a linux problem.
(In reply to xordevoreaux from comment #19) > ... > May not be a linux problem. Perhaps.
I can no longer reproduce this consistently.