Created attachment 104111 [details] Document that freezes writer Hi, Using Chrome, I copied the contents of this web page into a Writer document for reading offline: http://eloquentjavascript.net/04_data.html . Then, I went to Edit -> Links and broke all the links so I could read offline. However, Writer would crash unless I saved the document immediately. Now that I've saved the document, I can't scroll through it without Writer freezing. Also, PDF export doesn't work. Attached is the document.
Hello tgfyx, Thank you for submitting the bug. Does this crash happen on Windows, as it didnt happen for me on Linux? I was able to export it as well, though it took quite a bit of time, it eventually worked. I see the main problem is the svg squirrel image, as even breaking the link took quite some time to work.
Please 1 report = 1 issue. Separate the pdf export to a new bug report.
Seems like this is another 4.0.x introduced regression in images. In 3.6.7, the svg image is loaded with a small size though and if i stretch it to the margin, it still is fine with scrolling. Joel: I believe this is one issue with 2 symptoms, as the pdf export is trying to repaginate and the repaginate is slowed down similar to the scrolling. Also exporting from 3.6 isnt slow. :)
Attached file can't be bibisected as it gives the following error: Read-error. error reading file
Created attachment 104153 [details] Simplier file
Weird that you got a read error Xisco as i hadnt in any of the versions i tested.
I guess the error was fixed before the final release was done so you don't face it with the version you tested it, however, every bibisect's revision is done from a daily/every other day build so it's normal that this kind of error happen. it looks like this bug was introduced while the importer was broken so there's no way to bibisect it.
Created attachment 104186 [details] LibO 4.2.6 vs 4.3.1 (In reply to comment #1) > I was able to export it as well, though it > took quite a bit of time, it eventually worked. When i open the pdf exported in 4.2.6, which by the way is 2 times the size of the one produced by 4.3.1, when i reach page 2, okular revs up to 50% of CPU while it works on rendering the page. This doesnt happen in the 4.3.1 pdf export. (In reply to comment #3) > Seems like this is another 4.0.x introduced regression in images. In 3.6.7, > the svg image is loaded with a small size though and if i stretch it to the > margin, it still is fine with scrolling. It seems the svg is loaded with 3.6.7, 4.0.6, 4.1.6 and 4.2.6 with small size. In 4.3.1 it loads with a large size, which i assume is a regression. I overlooked this issue as when i pasted the contents from the webpage, all the images pasted were large. (In reply to comment #7) > I guess the error was fixed before the final release was done so you don't > face it with the version you tested it, however, every bibisect's revision > is done from a daily/every other day build so it's normal that this kind of > error happen. it looks like this bug was introduced while the importer was > broken so there's no way to bibisect it. Well i did test the daily build of 4.3.1, so its weird that it didnt show up.
that squirrel looks wicked, it must frighten the new SVG filter...
Created attachment 104457 [details] The squirrel in 3.3 (In reply to comment #9) > that squirrel looks wicked, it must frighten the new SVG filter... Check 3.3 and the squirrel is a dog. :) When was the new SVG filter introduced?
(In reply to comment #10) > > Check 3.3 and the squirrel is a dog. :) ha, the dog! that was a generic placeholder image, which was replaced by something else (i forget what) because it was considered politically incorrect (no seriously, bug 42782). > When was the new SVG filter introduced? first there was some SVG filter thing in go-oo (which is still used in LO for SVG import in Draw i guess). then Oracle decided to implement an "official" SVG import filter for OOo based on librsvg, and that went into OOo 3.4 beta and LO 3.4 or so, until LO 3.6. then the AOO project looked at its donated code base and Oracle's SVG filter became a victim of their LGPL witch-hunt, aka "IP Clearance", and Armin implemented a new SVG import that shipped with AOO 3.4, and was imported with the ALv2 re-base in LO 4.0. (this is the reason why we have so many SVG regressions vs. 3.6.)
Thanks Michael for the SVG background as it will help with the regression testing i'm always doing for bugs. :)
*** Bug 88413 has been marked as a duplicate of this bug. ***
The SVG filter replacement mentioned by mstahl in comment 11 is exactly the point mentioned in comment 7 where the squirrel stops importing. I think it's fair to declare this responsible for the performance regression - adjusting Whiteboard and Keywords to suit. (AOO 4.1.1 still fails to load the squirrel!) commit 44cfc7cb6533d827fd2d6e586d92c61d7d7f7a70 Author: Michael Meeks <michael.meeks@suse.com> Date: Tue Oct 9 12:22:23 2012 +0100 re-base on ALv2 code. Includes (at least) relevant parts of: ..... Patches contributed by Armin Le Grand Svg: Reintegrated Svg replacement from /branches/alg/svgreplavement
This bug is still present on 4.4.4.2 on ubuntu 14.04.
This bug is still present in 5.0.0.0beta3 on ubuntu 14.04.
In 5.0.0.5, the scrolling onto the squirel image takes ~2s and the export to pdf ~12s on my computer. So it seems the situation has largely improved. Not sure this behavior still qualify as a bug.
(In reply to Frederic Parrenin from comment #17) > In 5.0.0.5, the scrolling onto the squirel image takes ~2s and the export to > pdf ~12s on my computer. So it seems the situation has largely improved. Not > sure this behavior still qualify as a bug. In master, it freezes for 10-20s on my laptop and if i pass the squirrel and then go back to it, it repeats the freeze. Exporting to PDF takes 38s. Both incidents still cause one CPU core to jump to 100% until its done, so i wouldnt classify this to be fixed. Version: 5.1.0.0.alpha1+ Build ID: 25534a62b2ba398c6298c6b9e521f20de1087540 TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-08-07_14:13:33 Locale: en-US (en_US.UTF-8) CCing Meeks as his rebasement of Armin Le Grand code caused the issue according to comment 14.
Migrating Whiteboard tags to Keywords: (filter:svgInsert, perf, bibisected) Add filter:pdf
Checked the SVG deeper - it contains polygons filled with patterns. These patterns are huge. There are five of these, each containing 440 polygons. When these are used as fill style, they get repeated like a texture, so multiplying this immensely. What looks like gray is the result of a pattern with 440 small circles (each defined by a one-point polygon with set stroke-width:7.5). No wonder that also Inkscape and the browsers get slow, but not as slow as the office. This shows the potential for better renderers, but also the possibility to buffer resolution-dependent a single tile of this fill pattern. Checking...
Checked for the 1st polygon filled with that pattern - 571 tiles get created (or better: their transformations). This leads to 251240 polygons to be drawn for one to-be-filled polygon...
Looking deeper. Despite much data being processed, it is not (only) the renderer. I will check what can be done with the processing what means without touching the renderer for now...
Small note: Inkscape has problems and stops painting the dots starting at a zoom factor of 3256% - paint gets much faster with this error.
Created attachment 121934 [details] Callgrind from squirrel loading
Hi Jan-Marek, thanks for that. I did some runtime analysis already, (do you know VervSleepy? Also smart stuff). I can alredy say that it is a mixture of primitive handling, buffering and rendering. The first two can/should be adressed with this task, the third will be to general and big for this issue.
Armin Le Grand committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4609380bb0bde0d4437b72b752c1c24ee2950361 tdf#82214 optimize performance for primitives It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Armin Le Grand committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5046ebd813b2c155698f9664b629ca5587b8a28b tdf#82214 optimize PatternFillPrimitive and SVG It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hi Armin, Please, next time you assign a bug to yourself, remember to change the status and the assignee. Regards
Hello Armin, Is this bug fixed? If so, could you please close it as RESOLVED FIXED?
Adding Cc: to Michael Meeks
Indeed - Armin fixed this squirrel bug nicely - but since it shows up on the list of regression that I caused ;-> I'll mark it fixed for now - it's hugely faster. Thanks Armin !