Created attachment 204082 [details] File I tried to export. As I try to export a page into svg or emf/wmf format, it only creates temporal files like "lu952414z81.tmp" and ".~lock.MgHydrogenPatentTxtSeprtdFig3.svg#", and hangs up. The softwear indicates "no response" in its upper edge, where file name opened is indicated, and cannot be controlled. About ten minutes later, the app. shuts down by itself, and generates an error message saying that "エラードキュメントMgHydrogenPatentTxtSeprtdFig3の保存の際: 一般的なエラー. 一般的な I/O エラー。". (As saving the error document MgHydrogenPatentTxtSeprtdFig3, general error, general I/O error). The file I try to export is attached.
Confirmed. In version 25.8.2.2, the application hangs immediately upon opening the file and requires a force quit. In the dev version 26.2.0.0.alpha0+, the file will open successfully, but hang when trying to export to SVG. Tested in both: Version: 25.8.2.2 (X86_64) Build ID: d401f2107ccab8f924a8e2df40f573aab7605b6f CPU threads: 16; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 620(Build:0) CPU threads: 16; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Created attachment 204098 [details] WinDbg stack traces for process dumps during hung process, 1) when opening, 2) after some time and attempting to move in the Navigator (skVulkan rendering) and 3) SVG export (skRaster) There is a skia Vulkan rendering as vector issue but think it is the overly complex area fills for this ODG drawing causing the grief. With skia Vulkan based rendering enabled, the hang mentioned are present on initial launch and later if attempting to do anything, i.e. scroll the SB Navigator. But if I drop back to skia raster rendering--no issues to launch, manipulate or to export (to PNG). Yet, export of .odg to SVG also hangs, but eventually completes So suspect the issue is overly complex area fills for this document. Vaguely recall similar in past BZ issues but can't locate. Attaching Zip of 3 WinDbg stack trace with symbols of process dumps early and later in the skia Vulkan session. And then when exporting to SVG on open with Skia raster rendering. =-=-= Version: 25.8.3.2 (X86_64) Build ID: 8ca8d55c161d602844f5428fa4b58097424e324e CPU threads: 28; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
@Armin, Noel seems more a performance bottleneck in vector area fill drawing primitives? Could you take a peek.
(In reply to V Stuart Foote from comment #2) > > Yet, export of .odg to SVG also hangs, but eventually completes > Spoke too soon, the SVG export did eventually fail with the same general IO error. Only had seen the tmp and the file lock for the export.
So this is not any kind of drawinglayer or vcl performance issue. Some debugging reveals that the SVGWriter class is repeatedly exporting the same bitmaps over and over. I can see that the SVGWriter has some logic to try and cache bitmaps and only do the same bitmap once, but it does not seem to be working in this case. Xisco, you have worked on the SVGWriter before, perhaps you have some ideas?
(In reply to Noel Grandin from comment #5) > Xisco, you have worked on the SVGWriter before, perhaps you have some ideas? Hi Noel, unfortunately I've worked on the import part, not on the export part
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b7a51924b51b3a24891803141c108c21ba540ac5 tdf#169532 Improve draw/impress export to svg with lots of bitmaps 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.
WMF/EMF will need a separate report.