Created attachment 172198 [details] testcase The attached document has a full-page graphic object that is slow to draw when using e.g. mouse-wheel to scroll up and down. It is especially noticeable when using gtk3 VCL backend. The primary cost seems to be in VclProcessor2D::RenderFillGraphicPrimitive2D(), where it draws the object using ~10k tiny bitmaps.
Confirmed using LO 7.3.0.0.alpha0+ (612d5b1a04fe022a34018d901bb9b052791d54e5), 6.3.0.4 / Ubuntu. Scroll performance is better in 6.2.0.3 (not exactly snappy, but better). The change happened in the following commit, bibisected using bibisect-linux-64-6.3. I'm leaving the decision whether this should actually be considered a regression to someone else. https://cgit.freedesktop.org/libreoffice/core/commit/?id=86ea64f216819696cd86d1926aff0a138ace2baf author Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk> 2019-02-15 13:14:32 +0100 committer Tomaž Vajngerl <quikee@gmail.com> 2019-04-03 11:57:08 +0200 Support for native 32bit Bitmap in VCL and SVP (cairo) backend
The document has two graphic objects in it, Shape 3 and Shape 4, Shape 4 is in front of Shape 3. Shape 3 has an area filled with a 8x8 px pattern. That's the tiny bitmap with is drawn lots of times to fill the space. For me in an optimized gtk3 libreoffice-7-2 build under wayland this is not terrible. But if I use GDK_BACKEND=x11 then this is quite sluggish. In the identified commit the change to use CAIRO_OPERATOR_OVER from CAIRO_OPERATOR_SOURCE (which is the diff in SvpSalGraphics::drawBitmap does) for me triggers that slowdown in the end mbSupportsBitmap32 was defaulted back to false by... commit cd09fc9451897e6efedbf9f5e1d5b9bd96e65cb5 Date: Mon Mar 22 19:06:15 2021 +0100 do not enable mbSupportsBitmap32 for headless (tdf#141171) As said e.g. in 994b8e52fc02c7468a24 and 84f84f59ce7c83a99e4e340071d, LO code is not yet fully ready for 32bit bitmaps and e.g. PDF export code mishandles it. which suggests to me that we could also return to using CAIRO_OPERATOR_SOURCE without ill effect.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1727fe82330dcf67eeece4eacfd4907f85714b0f tdf#142394 return to using CAIRO_OPERATOR_SOURCE in drawBitmap 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.
dunno if performance can ever be said to be fixed but that presumably resolves the regression find, backport to 7-2 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/4e9f2b4fb8776aa438a6a3d3a5f4da961fb55d0b tdf#142394 return to using CAIRO_OPERATOR_SOURCE in drawBitmap It will be available in 7.2.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.