Description: In the latest versions of LibreOffice (version 7.0.2 or 7.0.3) the performance is very bad if a background image is set in the page layout templates. I use a full page background image (Jpeg, max 300kb) as stationery. The performance is fine if no background image is used. Other elements like tables or text boxes seem to have no influence on it. In the versions with the main version number 6 I did not have such problems. Steps to Reproduce: 1. Create a writer document and add a full page background image in the page layout template settings. 2. Try typing or other editing, performance very slow. Actual Results: The general performance in writer is very slow. Expected Results: Work normal like in documents without background image. Reproducible: Always User Profile Reset: No Additional Info: MAC OS Version 10.13.6
I tested this with the newest version 7.1.0.0alpha and this issue is also present there.
I can't confirm with Version: 7.0.3.1 (x64) Build ID: d7547858d014d4cf69878db179d326fc3483e082 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL Steps: 1. Format => Page Style => Area 2. Bitmap => Add/Import I'm not sure for 100%, that you did it the same way.
(In reply to Dieter from comment #2) > I can't confirm with > > Version: 7.0.3.1 (x64) > Build ID: d7547858d014d4cf69878db179d326fc3483e082 > CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: > win > Locale: de-DE (de_DE); UI: en-GB > Calc: CL > > Steps: > 1. Format => Page Style => Area > 2. Bitmap => Add/Import > > I'm not sure for 100%, that you did it the same way. Should be STR.. this is likely specific to Linux/macOS. Skia being optimized. Assuming bug 134809
Thank you for reporting the bug. 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 re-test? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present
I tried resetting the user, unfortunately with the same result. One more note, I don't know if it matters, I am German speaking and use umlauts accordingly. When typing quickly a word with umlauts like e.g. "Frühstück" (breakfast) the umlauts are twisted by the delay and it comes out something like "Fürühstck", even if I typed the word correctly (I tested this several times!).
Created attachment 168083 [details] Example file Type below images in the table.. I do reproduce this on Windows on GDI. Fine with Skia. Needs conformation with MacOS or Linux backend
@Jan-Marek This kind of side-step of the core bug (which doesn't require your expertise). However I have seen few reports similar to the report below. Which is processing the keyboard input in wrong order under heavily load. The bug here apparently exposes this for the moment (moving into shadows again after issue getting solved). And might be also related to the German keyboard (has ü a dedicated key?). And kind of relate this to timers (which is you're expertise).. And likely having a German keyboard might help too. Only hypothesis.. And not intending to 'drag' you into this as this is side-stepping the 'normal' procedure (not hypothesis confirmed). And developer time being precious thing.. But some code knowledge (and maybe German keyboard) kind of helpful to make sense of this.. > I tried resetting the user, unfortunately with the same result. > > One more note, I don't know if it matters, I am German speaking and use > umlauts accordingly. > When typing quickly a word with umlauts like e.g. "Frühstück" (breakfast) > the umlauts are twisted by the delay and it comes out something like > "Fürühstck", even if I typed the word correctly (I tested this several > times!).
> And might be also related to the German keyboard (has ü a dedicated key?). Yes, ä ü ö are dedicated keys on a german keyboard layout
(In reply to Telesto from comment #6) > Created attachment 168083 [details] > Example file > > Type below images in the table.. I do reproduce this on Windows on GDI. Fine > with Skia. Needs conformation with MacOS or Linux backend Yes, can confirm this under Mac (Version 10.13.6)
*** This bug has been marked as a duplicate of bug 138068 ***
Hello libre@gg6.at, I believe this issue might be fixed now after https://git.libreoffice.org/core/commit/27a4aea50a9efa5c839b0ae2de1f9f14a7782f11. Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ? You can install it alongside the standard version.
(In reply to Xisco Faulí from comment #11) > Hello libre@gg6.at, > I believe this issue might be fixed now after > https://git.libreoffice.org/core/commit/ > 27a4aea50a9efa5c839b0ae2de1f9f14a7782f11. > Could you please try to reproduce it with a master build from > http://dev-builds.libreoffice.org/daily/master/ ? > You can install it alongside the standard version. Thanks a lot, i've tried it with the nightly build 7.2.0.0 (2021-02-15_04.34.39) and my document that had this issue. And i can confirm: editing is fast like a rocket again. Hope this release is coming soon to the official build too!