Description: There is a bug in version 7 of Libre Office concerning memory management and fonts. When there are a lot of pictures, typing the text is very slow. In addition, all letters with accent shift and come before a syllable. Example: egeneration instead of generation. Steps to Reproduce: 1.There is a bug in version 7 of Libre Office concerning memory management and fonts. When there are a lot of pictures, typing the text is very slow. In addition, all letters with accent shift and come before a syllable. Example: egeneration instead of generation. 2. 3. Actual Results: There is a bug in version 7 of Libre Office concerning memory management and fonts. When there are a lot of pictures, typing the text is very slow. In addition, all letters with accent shift and come before a syllable. Example: egeneration instead of generation. Expected Results: There is a bug in version 7 of Libre Office concerning memory management and fonts. When there are a lot of pictures, typing the text is very slow. In addition, all letters with accent shift and come before a syllable. Example: egeneration instead of generation. Reproducible: Always User Profile Reset: Yes Additional Info: There is a bug in version 7 of Libre Office concerning memory management and fonts. When there are a lot of pictures, typing the text is very slow. In addition, all letters with accent shift and come before a syllable. Example: egeneration instead of generation.
Created attachment 167093 [details] fonts no correct
Is it possible to attach an example file illustrating the issue (so image + text). Maybe they file in the screenshot (or different demo file) to share publicly
They attachment's I found in the bug report. I was talking about they document shown inside they screenshot (or similar document) which exhibits they issue: "When there are a lot of pictures, typing the text is very slow."
Created attachment 167158 [details] Example file
Confirming slowness with GDI on Windows and also on MacOS Version: 7.1.0.0.alpha1+ (x64) Build ID: 5a96093f0ecee53432bdf35f247edd6deb501baf CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Bibisected using bibisect-win64-7.0 in GDI mode to: URL: https://cgit.freedesktop.org/libreoffice/core/commit/?id=828504974d70111e4a35b31d579cf42fe660a660 author: Armin Le Grand (Collabora) <armin.le.grand@me.com> committer: Armin Le Grand <Armin.Le.Grand@me.com> summary: tdf#130768 speedup huge pixel graphics Cairo Adding CC: Armin Le Grand
FWIW: not sure what the proper approach would be. GDI will reach EOL. So more at the level of MacOS. There is some talk about moving to Skia; not sure how realistic actually is. But of course waste of time to look into this is Skia will be implemented anyhow No clue if other (Linux) backends are affected too.
*** Bug 138808 has been marked as a duplicate of this bug. ***
*** Bug 138125 has been marked as a duplicate of this bug. ***
*** Bug 139068 has been marked as a duplicate of this bug. ***
@Xisco, There is likely a pretty big perf flaw at Linux/MacOS level related to images (Windows Skia unaffected) . Would be lovely if you could double/triple check this and maybe bumping priority even more.. The complains starting to drop in.. and we are going in the direction of 7.0.5
Bug 139068 is not specific to the 7.0 performance regression, it goes back much further than that. I have thus reopened that bug report and attached a new heavier sample that triggers the problem even on 6.3.x. With some luck, it may have some sort of underlying relationship with 138068 (here) but possibly not, and I suspect that even if you revert the regression from 7.0 the other performance bug might remain.
Unsubscribing. Feel free to add me back if you need more info from me. My bug report was: https://bugs.documentfoundation.org/show_bug.cgi?id=138808
(In reply to Jean-François Fortin Tam from comment #12) > Bug 139068 is not specific to the 7.0 performance regression, it goes back > much further than that. I have thus reopened that bug report and attached a > new heavier sample that triggers the problem even on 6.3.x. With some luck, > it may have some sort of underlying relationship with 138068 (here) but > possibly not, and I suspect that even if you revert the regression from 7.0 > the other performance bug might remain.
Bibisected this again on Linux with GTK3.. same result as comment 6 Bugs about this a trickling.. (see also are often duplicates) FWIW: there is also bug 139068 for 7.1 which maybe entangled.. So taking the the step to bump priority to maximum. Feel free to correct me if being wrong doing that
FWIW: this was present under Windows in the past: bug 88678. Sample file there should show the issue pretty well.. Nowday's OK with Windows (after Skia buffering)
*** Bug 139755 has been marked as a duplicate of this bug. ***
*** Bug 139993 has been marked as a duplicate of this bug. ***
Even if there is only one picture, keyboard input is very slow. It seems that the lag has disappeared in Windows 10 from version 7.1. However, in Linux, the input delay seems to be worse if there is still a picture.
Created attachment 169504 [details] Flamegraph On pc Debian x86-64 with master sources updated today + gen rendering, I don't reproduce the slowliness when typing anything after an image. I attached a Flamegraph but I don't think it'll help.
The document from comment #4 spends its time in DrawTransformedBitmap(). The problem is that if scaling is involved, it is left to Cairo to do it, and that is done by the CPU, thus relatively slow, and moreover each redraw needs that again and again. I don't know why the cache from Armin's change doesn't cache it, Skia code manages to cache it just fine. Either that cache needs to get fixed, or at least for the simple "at most translate+scale but no shear or rotate" case the scaling should be done manually using BitmapEx::Scale(), which should get cached. Skia's SkiaSalGraphicsImpl::drawTransformedBitmap() can be used as an inspiration for that case.
Created attachment 169513 [details] flamegraph
I confirm Comment 19: Even with only one image or picture of moderate size (about 600 kb) scrolling and typing gets very slow. I have tried it on Linux Mint 19.3 (Mate), Manjaro (Xfce, Virtual Machine), Ubuntu 20.4 (Gnome, Virtual Machine), as well as on Windows 10 (Virtual Machine). On Windows 10 the lagging appears not to be so profound as on Linux. Scrolling and typing remains very slow when LibreOffice is started in "safe mode". The type of the picture (foto, drawing, etc.) and the file-type (jpg, png, etc.) does make no difference in the behaviour. The slow scrolling and typing is only the case, if the image is visible in the document. If you scroll up or down past the image, and the image is out of the view pane, scrolling and typing speed reverts to normal. Linux Mint 19.3 Mate (normal install) Version: 7.0.4.2 Build ID: 00(Build:2) CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: de-DE Ubuntu package version: 1:7.0.4_rc2-0ubuntu0.18.04.2 Calc: threaded Manjaro 20.2 Xfce (normal install, Virtual Machine) Version: 7.0.4.2 Build ID: 00(Build:2) CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.utf8); UI: de-DE 7.0.4-3 Calc: threaded Ubuntu 20.4 Gnome (normal install, Virtual Machine) Version: 7.0.4.2 Build ID: 1c5f81ee28659974774060c3fe084e73b3bd074b CPU threads: 2; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded Windows 10 (normal install, Virtual Machine) Version: 7.0.4.2 (x64) Build ID: dcf040e67528d9187c66b2379df5ea4407429775 CPU threads: 3; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: threaded It also happened in the AppImage of the most recent release 7.1. The lagging in scrolling and typing appears to be even worse. Linux Mint 19.3 Mate (AppImage) Version: 7.1.0.3 / LibreOffice Community Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded The only thing that will make working with such a file possible is to show place holders for the graphics (Option: 'View Images and Charts'; Deutsch: 'Bilder und Diagramme'). ---------- There are *no* issues (even with several pictures inserted) in the latest 6.x Version of LibreOffice (tested as an AppImage). Linux Mint 19.3 Mate (AppImage) Version: 6.4.7.2 Build ID: 639b8ac485750d5696d7590a72ef1b496725cfb5 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: de-DE (de_DE.UTF-8); UI-Language: en-US Calc: threaded ---------- In Windows 10 and the most recent LibreOffice 7.1 the Problem seems to be solved (tested with the portable version). Windows 10 (portable version of LibreOffice) Version: 7.1.0.3 (x86) / LibreOffice Community Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 3; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: threaded
Perhaps we could revert: https://cgit.freedesktop.org/libreoffice/core/commit/?id=828504974d70111e4a35b31d579cf42fe660a660 while we try to work out how to avoid DrawTransformedBitmap continuing to be an expensive operation nearly everywhere. It is sad to have to have caches in the rendering backends cairo, skia etc. to accelerate this when my understanding is that a device resolution cached version of the output really belongs higher up in the drawing-layer. Anyhow the patch is not needed by us to solve any performance issue we see I think.
I have locally reverted the change (plus two related) and I can confirm that doing so noticeably improves the performance in this case. I don't know what other positive or negative effects it may have. Since doing the revert was non-trivial, I have posted it at https://gerrit.libreoffice.org/c/core/+/110588 , in case reverting is the decision (but I don't want to be the one making it).
(In reply to Luboš Luňák from comment #25) > Since doing the revert was non-trivial, I have posted it at > https://gerrit.libreoffice.org/c/core/+/110588 , in case reverting is the > decision (but I don't want to be the one making it). Lets divert responsibility to some kind of collective one, where everyone can point into circles. I did it because I'm told. I did it because agreed.. :P From me a go ahead; can't become worse, IMHO. Which means revert in Master.. Revert the revert is still an option, so.. Backporting has to wait +/- 8 days Hope that will be enough for some basic testing (especially checking for regressions as Skia). Hope it can make it into 7.0.6 (ideally around 21 February)
Possibly the low-level backends really are the best place to cache generated bitmaps, maybe with a little cooperation across the API, e.g. how we cache glyph renders for text. The low-level backends are the place that finally has all the relevant information available. I'm fairly sure Caolan implemented a cache for rendering pictures in writer, so I'm surprised another one (from Armin) was even necessary.
I tend to agree that this belongs rather in the lower levels. I'm admittedly not very knowledgeable about the higher levels, but I wonder how they would know how to actually do the caching. I mean, how can it know what the actual result will be, unless every place calling the lowlevel functions basically duplicates some of the logic? As for the cache in Writer, if these is one, then it apparently does not work. The only reason why the Skia backend is not hit by this is because it has its own implementation of a cache. And the Skia library provides SkImage::uniqueID() that changes on every content change, so it's pretty easy to do caching there. Possibly the only case when it wouldn't work and a cache might make sense on a higher level would be if there are places of code that modify the to-be-drawn bitmap on every invocation e.g. in order to apply transparency or some effect (i.e. the pixel data would be the same, but conceptually it would be a different bitmap). But even in that (IMO broken from a performance point of view) case I doubt higher levels would have an easier time caching that.
> As for the cache in Writer, if these is one, then it apparently does not > work. The only reason why the Skia backend is not hit by this is because it > has its own implementation of a cache. Actually I take that back. Apparently Armin's patch broke the Writer cache, reverting the commit makes the performance good even if I disable the Skia cache.
@Luboš Luňák: Please do not do it in this raw form. It will re-introduce bugs (on quick ref I just saw tdf#130768 in vcl/source/outdev/bitmap.cxx, there may be more. But also primitive buffering for writer bitmaps, VOC mechanism and SysDep BitmapBuffering - all that is needed and will be needed in future changes would be gone. Main problem seems to be that I preferred DrawTransformBitmapExDirect in vcl/source/outdev/bitmap.cxx cmpared to ther versions, that is the only thing that can influence stuff besides cairo. Please give me time to have a look to find a solution *without* taking back quite some stuff already done for a better future...
For reference, the Caolan caching I was talking about was commit 9f3926df5c2828ad3e8cfce2b4444b1c84352cf4, tdf#123165, which is pretty much the same bug as this one
(In reply to Armin Le Grand from comment #30) > Main problem seems to be that I preferred DrawTransformBitmapExDirect in > vcl/source/outdev/bitmap.cxx cmpared to ther versions, that is the only > thing that can influence stuff besides cairo. I confirm, it's really just this part that causes the performance problem. So https://gerrit.libreoffice.org/c/core/+/110716 should be enough for this bugreport. (In reply to Noel Grandin from comment #31) > For reference, the Caolan caching I was talking about was commit > 9f3926df5c2828ad3e8cfce2b4444b1c84352cf4, tdf#123165, which is pretty much > the same bug as this one That's not a Writer cache though, that's a cache for the best quality BitmapEx::Scale() algorithm. So I assume what's happened was that Armin's patch made DrawTransformBitmapExDirect() preferred to DrawBitmapEx() that does BitmapEx::Scale() internally, but all backend implementations for DrawTransformBitmapExDirect() except the Skia one use uncached and possibly slow platform API for the scaling, hence the slowdown.
@Luboš Luňák: Thanks, that is much better. But you mention the reason behind it: We have too many methods at LowLevel stuff to draw Bitmaps - of course of historical reasons. We need DrawTransformBitmapEx anyways, so all other cases *could* and *should* be elliminated. The low-level impls may locally switch to old versions (e.g. when not reanny rotated or scaled), but the API shpuld be greatly simplified - what was the plan from the beginning - but - sigh... Same for Polygon paint, BTW. Same for all methods that still have integer API - sigh... And of course this also means that something like this can happen at all - of course DrawTransformBitmapEx should do the *same* buggering if possible that a simple DrawBitmapEx probably currently does. When we would only have DrawTransformBitmapEx it could not be added on a specialized place, ignoring other cases. In practise this means if anyone should *dare* to update the API usage to paint char bitmaps in SW to use DrawTransformBitmapEx (which some systems can directy supposrt in HW, so we need it to be able to use *that*) we will be back with this error... I had hoped that when doing a new backend like skia it would be a good point in time to reduce the API in that sense - would've made impl easier, too. Or -as suggested - get rid of all of this - and just have some GetProcessor2D from backend - call which you could then feed *any* kind of primitives - just dreaming, this is the mid-term (far?) future...
Luboš Luňák committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9d89d98d3349502b56da4bdd6ea287ac4cde9ce5 always optimize bitmap transform to translate+scale if possible (tdf#138068) It will be available in 7.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.
Luboš Luňák committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/27a4aea50a9efa5c839b0ae2de1f9f14a7782f11 always optimize bitmap transform to translate+scale if possible (tdf#138068) It will be available in 7.0.5. 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.
I do confirm the issue is fixed in Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: cbcec4425e04e3614a2025b49fdc221216ac51d3 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded @Luboš Luňák, thanks for fixing this issue. Should it be closed as RESOLVED FIXED ?
*** Bug 136265 has been marked as a duplicate of this bug. ***
*** Bug 134241 has been marked as a duplicate of this bug. ***
*** Bug 137841 has been marked as a duplicate of this bug. ***
*** Bug 139925 has been marked as a duplicate of this bug. ***
Luboš Luňák committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/b6d67d3d18d46daaabb3532d176759c234196da7 always optimize bitmap transform to translate+scale if possible (tdf#138068) It will be available in 7.1.2. 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.
Yes, I think we can consider this fixed.
Luboš Luňák committed a patch related to this issue. It has been pushed to "libreoffice-7-1-1": https://git.libreoffice.org/core/commit/7a0b7ef6d490e7ed7c35874b3feca75c79effdb7 always optimize bitmap transform to translate+scale if possible (tdf#138068) It will be available in 7.1.1. 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.
The scaling quality in gtk3+cairo has gotten worse since this change was added. I opened a new bug [1] tdf#140768 with the issue. [1] https://bugs.documentfoundation.org/show_bug.cgi?id=140768
*** Bug 141131 has been marked as a duplicate of this bug. ***
I don't understand why this is considered fixed; performance is still significantly worse than it was in 6.4.7 if images are used and the "fix" seems to have broken anti-aliasing, which may explain the slight performance improvement. Just to clarify: on Fedora 33 using a normal Writer doc where some pages have several images: version 6.4.7: performance good, image quality good version 7.0.4: performance bad, image quality good version 7.0.5: performance slightly less bad, image quality bad On version 7.0.5 the images are not anti-aliased, no matter if the option is turned on or not...in fact, this option doesn't seem to be doing anything anymore, which is probably where the slight performance improvement comes from. Personally I have reverted to 6.4.7 until this is properly fixed. PS: it's less bad on Windows 10, but still not optimal.
That's my experience too, although for me performance is good. But that could be because my graphics card is just quite good.
For Chrifo and Alberto: please confirm that you tested with LO master.
I have tested it with the latest development Appimage.
I don't know what "LO master" means, but I have just downloaded the 7.1.2.2 version from the documentfoundation servers to test it on Fedora 33 and it is definitely much better than 7.0.5! Performance for me is still a bit worse than 6.4.7, but significantly better than 7.0.5 and the anti-aliasing option there works. So from my perspective there is still room for improvement but at least it doesn't feel like a huge step back.
(In reply to chrifo.cf from comment #51) > I don't know what "LO master" means, but I have just downloaded the 7.1.2.2 > version from the documentfoundation servers to test it on Fedora 33 and it > is definitely much better than 7.0.5! Performance for me is still a bit > worse than 6.4.7, but significantly better than 7.0.5 and the anti-aliasing > option there works. > > So from my perspective there is still room for improvement but at least it > doesn't feel like a huge step back. Please create a new bug report and add a sample file. This is probably Linux only and and specific to the back-end used: GTK3 /QT
Sorry for taking so long... On my end of things there is no issue anymore, the performance is good! Since no one else has replied with persisting issues in the meantime I will close the issue since it was my reported problem that reopened it.