Created attachment 114837 [details] Example document showing slow scroll behavior Description: In LibreOffice 4.4.x, there is a serious rendering performance regression when viewing items with backgrounds set to an image under Linux. This seems to affect applying image backgrounds to pages, frames, tables paragraphs, etc... This is most noticeable when simply scrolling up/down with the mouse wheel, but also affects typing or any type of editing. While using certain documents, it is quite noticeable when running LO locally, it can make using LO painful over a LAN, and practically unusable across the internet. I discovered this behavior while looking at bug 88678. While this might be somewhat similar, I'm pretty confident that this is a different bug. It also seems similar to bug 89204 with poor rendering performance when any images that are NOT a background are inserted. I've attached a simple example file that contains a frame with its background set to an image. I've bibisected: 9d57c189d74551d2b3770cc81139ea10a62e672f is the first bad commit commit 9d57c189d74551d2b3770cc81139ea10a62e672f Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Mon May 12 05:19:54 2014 +0000 source-hash-5b5e62650354788e50b44f32c22b687b2018aba9 commit 5b5e62650354788e50b44f32c22b687b2018aba9 Author: Stephan Bergmann <sbergman@redhat.com> AuthorDate: Fri Mar 28 15:22:57 2014 +0100 Commit: Stephan Bergmann <sbergman@redhat.com> CommitDate: Fri Mar 28 15:23:09 2014 +0100 Remove remaining DBG_CTOR etc. remnants from chart2 Change-Id: Iaf07f77b4228d4debb2620625b14ce7dc41e3a98 :100644 100644 9506902c6a27010b21fa60db2785cf8c6a99663b b7caf44d24c70027187d09beb9d1a84d3c2251d5 M ccache.log :100644 100644 f131bc060e8059666f8d7f3d448a0a6b8e1df7e4 67e626a238104bf7e45c40698e0e7cc28a4cd98c M commitmsg :100644 100644 5db1c1712e795b3ab96960366a53cf84ae3d8bca e6b0918bbb842858c3ad70bde38bc555a88e1bf0 M make.log :040000 040000 6dbe8a26ebf7cb34dc34ce783aa54092c2e9e5ed 0be05708421a37d2d8695098f2569749e3ed39de M opt $ git bisect log git bisect start 'latest' 'last42onmaster' # good: [4fcd68ce4979f85fda4568f4b419a4b41d07345f] source-hash-2c4621c87ed3a7b19de195c21494c9a381e72b2e git bisect good 4fcd68ce4979f85fda4568f4b419a4b41d07345f # skip: [422186458e0b4db00c7e26b54d5b631f83bcad2a] source-hash-6948bf58ce181b17f60ef81f10205ef4dac50cc6 git bisect skip 422186458e0b4db00c7e26b54d5b631f83bcad2a # bad: [a0b33bffff9c787dce71a13b344f06ae1453026b] source-hash-02e0be069e57e724c51f23e2e31b77657a6a1d3d git bisect bad a0b33bffff9c787dce71a13b344f06ae1453026b # good: [db29eee512d03b1dc0139b3752bbe7931b165377] source-hash-77b6c1602aaa0bd059077765e7fabb53d9e6ddeb git bisect good db29eee512d03b1dc0139b3752bbe7931b165377 # bad: [9d57c189d74551d2b3770cc81139ea10a62e672f] source-hash-5b5e62650354788e50b44f32c22b687b2018aba9 git bisect bad 9d57c189d74551d2b3770cc81139ea10a62e672f # good: [54cb1e734a8a8afb71a38fb1ff0f61103af44147] source-hash-1b922da415339726fb0186246dba6a03429b33bf git bisect good 54cb1e734a8a8afb71a38fb1ff0f61103af44147 # good: [1b831d02ff29aa5763cf33ae75131f98d882201f] source-hash-b7c3e851465638d4416ca8837937946353561088 git bisect good 1b831d02ff29aa5763cf33ae75131f98d882201f # good: [a6c3773eefb6c6ea2e1a8ad980c258c07a1a8e65] source-hash-4f48dc2f978d36ef9ba08bf828894fa578430fc7 git bisect good a6c3773eefb6c6ea2e1a8ad980c258c07a1a8e65 # good: [d888081586d217a52fd06ce89f146aa4080b4ca9] source-hash-722c82b018327c1f9578ddc533ebbb06080848eb git bisect good d888081586d217a52fd06ce89f146aa4080b4ca9 # first bad commit: [9d57c189d74551d2b3770cc81139ea10a62e672f] source-hash-5b5e62650354788e50b44f32c22b687b2018aba9
I'm upping the importance to Major/High because it involves a serious glitch, making using LO remotely tediously slow. It is also a regression.
I can confirm this. Had not tried 4.4 yet and boy was I shocked when using thin clients... this bug (and bug 89204) are really bad. Major regression in performance.
Please don't set the priority for your own bugs - there is no way to be objective about it. IMHO: Minor - can slow down but will not prevent high quality work; High - serious enough regression to be pushed to high I'm not going to change this one as I don't want to get in some screaming war over priorities but objectively, this one is not correct. Major should be loss of data, crashes, etc....
(In reply to Joel Madero from comment #3) > Please don't set the priority for your own bugs - there is no way to be > objective about it. > > IMHO: > > Minor - can slow down but will not prevent high quality work; > High - serious enough regression to be pushed to high > > I'm not going to change this one as I don't want to get in some screaming > war over priorities but objectively, this one is not correct. Major should > be loss of data, crashes, etc.... Setting to High/Minor, as suggested. For what it's worth, I try to use your bug priority triage flowchart whenever I'm attempting to prioritize ANY bug, including my own. According to that flowchart, loss of data or crashes warrant critical or blocker status, not major. https://wiki.documentfoundation.org/File:Prioritizing_Bugs_Flowchart.jpg
@tmacalp: Not sure if you got my email, but I built a targeted bibisect repository you could possibly use to narrow this down further (covering all the commits in the range you identified) - I would do it myself but I can't reproduce this locally. If you're having any problems, feel free to drop me an email or grab me in #libreoffice-qa
Here is the bibisect using Matthew's targeted bibisect repo: 7fd8078970675ec1bf6a2972ecfa7cf22455536f is the first bad commit commit 7fd8078970675ec1bf6a2972ecfa7cf22455536f Author: Matthew Francis <mjay.francis@gmail.com> Date: Mon Apr 20 18:32:15 2015 +0800 source-hash-6e61ecd09679a66060f932835622821d39e92f01 commit 6e61ecd09679a66060f932835622821d39e92f01 Author: Armin Le Grand <alg@apache.org> AuthorDate: Wed Mar 19 16:17:02 2014 +0000 Commit: Miklos Vajna <vmiklos@collabora.co.uk> CommitDate: Fri Mar 28 14:31:08 2014 +0100 Merge back branch alg_writerframes to trunk (cherry picked from commit b635b4fa4e42053d30ab639643d2236a20243f62) Conflicts: comphelper/inc/comphelper/TypeGeneration.hxx comphelper/source/property/TypeGeneration.cxx cui/source/factory/dlgfact.hxx cui/source/inc/cuitabarea.hxx cui/source/tabpages/tabarea.cxx cui/source/tabpages/tabarea.hrc cui/source/tabpages/tabarea.src cui/source/tabpages/tparea.cxx drawinglayer/source/primitive2d/polypolygonprimitive2d.cxx drawinglayer/source/processor2d/vclmetafileprocessor2d.cxx drawinglayer/source/texture/texture.cxx editeng/inc/editeng/unotext.hxx editeng/source/items/frmitems.cxx include/drawinglayer/texture/texture.hxx include/editeng/brushitem.hxx include/svx/sdr/primitive2d/sdrdecompositiontools.hxx include/svx/svxids.hrc include/xmloff/xmltypes.hxx reportdesign/source/ui/misc/UITools.cxx sc/source/ui/drawfunc/drawsh.cxx sfx2/source/dialog/tabdlg.cxx svl/source/undo/undo.cxx svx/inc/svx/unoshprp.hxx sw/Library_sw.mk sw/inc/doc.hxx sw/inc/format.hxx sw/inc/frmfmt.hxx sw/inc/swatrset.hxx sw/inc/unomap.hxx sw/inc/unoprnms.hxx sw/source/core/access/accpara.cxx sw/source/core/attr/format.cxx sw/source/core/attr/swatrset.cxx sw/source/core/doc/docdraw.cxx sw/source/core/doc/docfly.cxx sw/source/core/doc/notxtfrm.cxx sw/source/core/inc/frame.hxx sw/source/core/inc/frmtool.hxx sw/source/core/layout/atrfrm.cxx sw/source/core/layout/paintfrm.cxx sw/source/core/text/inftxt.cxx sw/source/core/text/porfld.cxx sw/source/core/text/txtfly.cxx sw/source/core/txtnode/fntcache.cxx sw/source/core/uibase/app/docst.cxx sw/source/core/uibase/app/docstyle.cxx sw/source/core/uibase/shells/drawdlg.cxx sw/source/core/uibase/shells/frmsh.cxx sw/source/core/unocore/unoframe.cxx sw/source/core/unocore/unomap.cxx sw/source/core/unocore/unoprnms.cxx sw/source/core/unocore/unostyle.cxx sw/source/ui/fmtui/tmpdlg.cxx sw/source/ui/fmtui/tmpdlg.src sw/source/ui/frmdlg/frmdlg.cxx sw/source/ui/frmdlg/frmpage.src sw/source/ui/inc/frmsh.hxx xmloff/source/text/txtprhdl.cxx xmloff/source/text/txtprmap.cxx Change-Id: Id3ffaa83bb5594d287f1ac8f2c1c9cf55c70946d :100644 100644 ebc766b58ab816dcb0d77ff3489c48ce9eb62c32 5ce3b860a652bbd62c8ac61bbb52d71b8386c959 M ccache.log :100644 100644 45e1ed288fe14622167796774c2fa897acac51a9 b76f81cdcda017f9d45e555108b12582df670be9 M commitmsg :100644 100644 d5c434fb225777c13d577e68312aaa139dc820a9 1a959b061c75392563e1fc29d3bfad6c8a5927b7 M make.log :040000 040000 cf915096292d2ce240cb0a3345a5fb0c717ba7d8 3c65bd4161d0280750215b9fd4824d0896cb019e M opt $ git bisect log git bisect start 'latest' 'oldest' # good: [3c09a4a6e41c3d0f3ceaddab66b07aae6c2ff8bf] source-hash-a69209a4152c6e8a64e8467dffa9c4330fd2112f git bisect good 3c09a4a6e41c3d0f3ceaddab66b07aae6c2ff8bf # good: [804315cad2149c3e98542313948e396b72a6e827] source-hash-67780ee7f37f05ebdec0d330361fa80e1f2e0cc8 git bisect good 804315cad2149c3e98542313948e396b72a6e827 # bad: [cb39d1419e8b65ef4736a10ccad6d14ee2054425] source-hash-1d3e4bc3b65a696d67ef9c157e67a03e8f37e08d git bisect bad cb39d1419e8b65ef4736a10ccad6d14ee2054425 # good: [1321f7b4401a68f7667c158b891907c5334a616d] source-hash-c7190108f02921868cb617040aebdb2d22c02c1f git bisect good 1321f7b4401a68f7667c158b891907c5334a616d # bad: [d52172f58567951b2d56090365e7ab23fa0cb407] source-hash-d757a98001a65baf4066c2eda037a08ab1beda46 git bisect bad d52172f58567951b2d56090365e7ab23fa0cb407 # bad: [7fd8078970675ec1bf6a2972ecfa7cf22455536f] source-hash-6e61ecd09679a66060f932835622821d39e92f01 git bisect bad 7fd8078970675ec1bf6a2972ecfa7cf22455536f # first bad commit: [7fd8078970675ec1bf6a2972ecfa7cf22455536f] source-hash-6e61ecd09679a66060f932835622821d39e92f01
Removing comma from Whiteboard (please use a space to delimit values in this field) https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Whiteboard#Getting_Started
Migrating Whiteboard tags to Keywords: (bibisected, perf)
Hi tmcalc, * I have the impression that it works ~fine in a recent daily build and 5.2.1.1 Can you please check this Thanks! Cor
Hi Cor, You shouldn't change the status back to NEEDINFO once the bug has been confirmed by someone. Please change the status to RESOLVED WORKSFORME if you believe this bug is fixed. Meanwhile, I change it back to NEW
(In reply to Xisco Faulí from comment #10) > Hi Cor, > You shouldn't change the status back to NEEDINFO once the bug has been > confirmed by someone. > Please change the status to RESOLVED WORKSFORME if you believe this bug is > fixed. Meanwhile, I change it back to NEW I thought asking was polite, but resolving is fine for me