| Summary: | [GTK] selecting a shape increases memory use up to 1.3 GB, creates visual artifacts in GUI | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Stéphane Guillou (stragu) <stephane.guillou> |
| Component: | Writer | Assignee: | Caolán McNamara <caolan.mcnamara> |
| Status: | VERIFIED FIXED | ||
| Severity: | normal | CC: | buzea.bogdan, caolan.mcnamara, telesto |
| Priority: | medium | ||
| Version: | 6.2.5.2 release | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| See Also: | https://bugs.documentfoundation.org/show_bug.cgi?id=142983 | ||
| Whiteboard: | target:7.3.0 target:7.2.0.2 | ||
| Crash report or crash signature: | Regression By: | ||
| Bug Depends on: | |||
| Bug Blocks: | 103182, 122652 | ||
| Attachments: |
visual artifacts in UI
i confirm the bug. if computer has less then 4g free libreoffice shuts down. if not it waits and work. i see it consuming memory of the pc. is going to consume memory... start memory end memory 6,6 gb memory going up |
||
|
Description
Stéphane Guillou (stragu)
2021-07-08 11:53:28 UTC
Created attachment 173446 [details]
visual artifacts in UI
A screenshot of visual artifacts seen when continuing using Writer after the memory issue.
Created attachment 173450 [details]
i confirm the bug. if computer has less then 4g free libreoffice shuts down. if not it waits and work. i see it consuming memory of the pc.
Created attachment 173453 [details]
is going to consume memory...
Created attachment 173454 [details]
start memory
Created attachment 173455 [details]
end memory 6,6 gb
Comment on attachment 173455 [details]
end memory 6,6 gb
6,6 - 3,8 = 2,8
it consumes 2,8gb gb memory...
Created attachment 173457 [details] memory going up Confirm also with Version: 7.1.4.2 / LibreOffice Community Build ID: a529a4fab45b75fefc5b6226684193eb000654f6 CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: en-US (ro_RO.UTF-8); UI: en-US Calc: threaded Also in Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: eac5977bfc11797eda356560a5e45c51108ef5a1 CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded Thanks Paulo and Bogdan! Seems to be GTK-specific. I tried without GTK: /opt/libreofficedev7.2/program/soffice -env:SAL_USE_VCLPLUGIN=gen --writer ...and didn't get the same drastic increase in memory use (it only went from 100 to 150 mb, I could move the shape around, it didn't disappear... I could see in the terminal the following warning pop up every time I move the shape around, in case it helps understanding the issue: warn:legacy.osl:20977:20977:svx/source/svdraw/svdmrkv1.cxx:311: SdrMarkView::UndirtyMrkPnt(): Selected points on an object that is not a PolyObj! I don't think isn't a gtk think but is a generic unix/X thing in that selecting the shape makes it a candidate for the "primary selection" and for some (rather odd look reason) we're generating a huge bitmap from it in case we want to paste it into some other application while the usual pattern is just to state that its possible to paste as that format and not generate it until its explicitly requested. I think we can defer creating this large transfer bitmap until the moment something actually wants it during a drop, which is the usual pattern for this sort of thing and what I see we're doing with the standard writer images (as opposed to these drawings) Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2012d5b90b64cb3a28862267dafb162c2f85d832 tdf#143257 like graphics defer creating transfer data for drawings until needed It will be available in 7.3.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. fixed in devel, backports in gerrit Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/bcccbf1a8d8891b7dc60122a380cf648d2998995 tdf#143257 like graphics defer creating transfer data for drawings until needed It will be available in 7.2.0.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. No problem now. Thanks for this fix. Very important! Verified with Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: c6695a4aabeaae99174b7658f2b813788ecff7f0 CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded Thank you, Caolán! No memory increase when selecting the shape in a recent build of master. Now, if the shape is copied, we still get the memory increase, and I can see the UI issues in Writer. Should a different bug report be opened about this, that would probably apply to any operating system? What do you think is the reason for that particular shape to hog memory like that when copied? Is it just that it is huge in size, and therefore we only need Bug 142983? FYI, when pasted into Inkscape, the size of the object is about 587 × 182 cm. (In reply to stragu from comment #16) > Should a different bug report be opened about this, that would probably apply to any operating system? It would presumably affect all platforms by the time of paste > What do you think is the reason for that particular shape to hog memory like > that when copied? I don't really know, but problems like this have shown up in the past with things like very long dashed/dotted lines which, while they might get cropped in the end, generate large amount of line segments. |