https://bugs.documentfoundation.org/show_bug.cgi?id=163887
--- Comment #8 from [email protected] <[email protected]> --- I've bisected it to this commit: commit 1acd37a671b9d3633a7d31a0b60478815fbc685f Author: Armin Le Grand (Collabora) <[email protected]> Date: Fri Sep 13 11:42:27 2024 +0200 CairoSDPR: Activate globally to check builds/tests This is to check all builds/tests with activated CairoSDPR to evtl. make needed additional changes as preparation to activate this in the future. adapted for testTdf139000(): Use no AA offset (0.5) for applying mask. Adapted for testDoublePixelProcessing: The trick (hack) to create a PixelProcessor and then attact a metafile to start recording to it does no longer work/make sense since the VclPixelProcessor2D is no longer the only PiyelProcessor you might get. If it is a SDPR one (e.g. CairoSDPR) it *cannot* record metafiles - and is not intended to do so. Since this test was already adapted 6 years ago to the modernized decompose of a double line to just two lines anyways it is OK to now change to use a VclMetafileProcessor2D now initially. Adapted for CppunitTest_svgio: In SvgFeBlendNode::apply execute the calls for convertToBitmapEx without AntiAliasing to get better edges. Input data is SVGToken::FeFlood, so a rectangular area, so no AA needed. Taking this back: The reason must be in the renderer, nothing else changed. Debugged in detail through both, problem is that VclPixelProcessor2D ends up in CairoCommon::drawPolyPolygon and draws the polygon AntiAliased, but just the fill and thus *not* with the AA-offset of 0.5, that is only done for fill. I have to re-consider the AA offset decision for filled polygons. Checked CairoCommon again, indeed AA offset is ony done for lines, not for fill - that corresponds with my thoghts from the weekend. Somehow this must have come in with copy/paste (?). Same is already in D2DPixelProcessor2D, have to remove there, too. Adapted for CppunitTest_sd_png_export_tests: This was a hard one, debugged all the components used for ConvertToBitmap/MaskCreation. Cumulated to be some diff in processTransparencePrimitive2D, but found no error after checking all tranmsformations. The orig errof ro the failing test (tdf#158743) seemed to give a hint, but ObjectTransformation was just handled well. At the end the diff was that VclProcessor2D uses the same processor, while CairoPixelProcessor2D creates local instances (what is cheap). Thus the content rendering for TransparencePrimitive2D was *not* using the set BColorModifierStack. Added as needed to be able to transfer that to the content rendering instance. Adapted for CppunitTest_sd_png_export_tests: Gerrit says PNGExportTests.cxx:1041 asserts, but I cannot reproduce. Maybe at the build system a slightly different font is used. My only idea is to add the mentioned point at (12,120) to the rectangles, obviously the bottom one. Next one is (13,82), again bottom one, adapting. Adapted for CppunitTest_sw_ooxmlexport16: The test 'testTdf136841' uses a WMF that contains XOR paint parts. This showed that that part in CairoSDPR did not work yet as needed. Adapted that, also the test slightly due to the color result slightly changed with CairoSDPR. One last change before activating in master: Add DISABLE_SYSTEM_DEPENDENT_PRIMITIVE_RENDERER in case it urgently needs to be switched off or to be able to simply test if something happening is related to CairoSDPR Change-Id: Idb8237a05d7594efe20edfa1707ca0002185645a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173330 Tested-by: Jenkins Reviewed-by: Armin Le Grand <[email protected]> It appears from the commit comment that this change resulted in a test failure that the committer could not reproduce. This sounds a little similar to the current bug. -- You are receiving this mail because: You are the assignee for the bug.
