When I export a slide to PNG from Draw having text converted to a curve or polygon and the text is set transparent, Windows Task Manager shows "VERY HIGH" for power usage for LO both while the PNG export dialog is preparing to display on the screen and then again while saving.
The saving process takes considerably longer than slides without transparency (or with transparency and exporting via TIFF).
This does not occur when exporting TIFF files.
Note: This does not happen with other transparent objects, just text that's been converted to a curve (OR POLYGON) and that curve/polygon made transparent.
Text converted to a curve/polygon but not made transparent does not hinder the export process.
Steps to Reproduce:
1. Open LO Draw
2. Import a picture
3. On top of that picture, type some text.
4. Convert text to a curve
5. Set the text's transparency to something other than 0.
6. Export the slide as PNG
Manager shows "VERY HIGH" for power usage for LO both while the PNG export dialog is on the screen and then again while saving.
Power usage and export time should be essentially no different for transparent objects on a slide when exporting to PNG as opposed to another format like TIFF.
User Profile Reset: No
Windows 10 Pro Version 1901 Build 19363.476
nVIdia GTX 1050 with driver version 441.20 released Nov 12 2019.
3770 K I7 64 Bit Processor
What I experienced happens regardless if hardware acceleration is on or off or if Open GL is used. I usually work with Open GL off and with hardware acceleration and anti-aliasing on.
Because I have not been using transparent text until now, I do not know whether this is something new with 18.104.22.168 or would have been happening in earlier versions.
Created attachment 155934 [details]
For the attached LO draw file to test with for exporting PNGs:
1. Slide 1 exports normally
2. Slide 2 exports normally
3. Slide 3 has a transparent text converted to a curve and hinders export
4. Slide 4 exports normally
5. Slide 5 has a transparent text converted to a polygon and hinders export
6. Slide 6 exports normally having a transparent square on it.
Sorry, I mistyped.
I'm using Windows 10 Pro 1909 build 18363.476, not 1901, as stated originally.
So the problem is when exporting page 3 ?
I can't reproduce it in
Build ID: b9d6ea1dd7541c4bd866571f9e3f0aa894687c07
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3;
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
To be certain the reported issue is not
related to corruption in the user profile, could you please reset your
Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and
I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' if the issue is still present
(In reply to Xisco Faulí from comment #3)
> So the problem is when exporting page 3 ?
> I can't reproduce it in
> Version: 22.214.171.124.alpha0+
> Build ID: b9d6ea1dd7541c4bd866571f9e3f0aa894687c07
> CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3;
> Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
> Calc: threaded
> To be certain the reported issue is not
> related to corruption in the user profile, could you please reset your
> Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and
> I have set the bug's status to 'NEEDINFO'. Please change it back to
> 'UNCONFIRMED' if the issue is still present
um... from the above, looks like you tested in Unix/Linux.
I am working in Windows.
Far be it the case from the many bugs I've posted that Windows bugs always appear in Unix/Linux. Almost every time a developer comes back on one of my bugs that that they couldn't reproduce it, they weren't testing in Windows.
Test in Windows 10 please.
Created attachment 156493 [details]
WINDOWS 10 TASK MANAGER DURING EXPORT OF PNG
This high level of CPU usage only happens with transparent text. Does not happen, as shown in my previously posted test file for this bug (128888), illustrates.
Putting LO in safe mode made (default user profile) no difference.
CPU usage was the same both at the time the export dialog box tried to appear on the screen and during the export process itself. Again, this is happening on slide #3 of my originally posted test file in this bug when exporting to PNG.
I don't observe any exceptional CPU cycles when the export dialog is open. Sure, it uses some CPU for a couple of seconds while exporting (both on Windows and Linux). How is this a bug, though?
"Power usage and export time should be essentially no different for transparent objects on a slide when exporting to PNG as opposed to another format like TIFF."
Why not? They are different formats after all with their own compression methods. Notice there is a slider for compression level in the PNG export dialog.
Arch Linux 64-bit
Build ID: 6a9c7409ee617b79c327dd7ea4de432f448b6006
CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: kf5;
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Built on 24 April 2020
I'm tired of trying to state a case for this so I'm just killing it.