<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Slow drawing of semi-transparent large color object" href="https://bugs.documentfoundation.org/show_bug.cgi?id=142394#c2">Comment # 2</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Slow drawing of semi-transparent large color object" href="https://bugs.documentfoundation.org/show_bug.cgi?id=142394">bug 142394</a> from <a class="email" href="mailto:caolanm@redhat.com" title="Caolán McNamara <caolanm@redhat.com>"> Caolán McNamara</a> <pre>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 (<a class="bz_bug_link bz_status_VERIFIED bz_closed" title="VERIFIED FIXED - FILESAVE: PDF: PNG images are exported as black" href="show_bug.cgi?id=141171">tdf#141171</a>) 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>