Thank you for reporting the bug. I can confirm that the bug is present in

Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 866538a4aeb30a598a6ede3d1763d898eb1920b0
CPU threads: 2; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Of note, shadows display properly in an earlier version:

Version: 24.2.7.2 (X86_64) / LibreOffice Community
Build ID: 420(Build:2)
CPU threads: 2; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Ubuntu package version: 4:24.2.7-0ubuntu0.24.04.4
Calc: threaded

Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 1acd37a671b9d3633a7d31a0b60478815fbc685f
CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: ja-JP (ja_JP.UTF-8); UI: en-US
Calc: threaded

works fine. with SAL_USE_VCLPLUGIN=gen
Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 1acd37a671b9d3633a7d31a0b60478815fbc685f
CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: x11
Locale: ja-JP (ja_JP.UTF-8); UI: en-US
Calc: threaded
and
Version: 25.2.3.2 (X86_64) / LibreOffice Community
Build ID: bbb074479178df812d175f709636b368952c2ce3
CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win
Locale: ja-JP (ja_JP); UI: ja-JP
Calc: CL threaded

Probably Linux only.

author	Armin Le Grand (Collabora)
commit 1acd37a671b9d3633a7d31a0b60478815fbc685f

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

Using 'DISABLE_SYSTEM_DEPENDENT_PRIMITIVE_RENDERER=1' is good tocheck if this has to do with CairoSDPR, in this case it shows some shadow when using, so yes.

It seems to be a feature not completely/well implemented/complete (?) that I did not even know about. Since Draw/Impress uses Primitives it has somehow to be done internally using Primitives - that is good.
It is not completely broken: Besides being incredibly slow selecting that left graphic seems to show no shadow. When looking at the Sidebar/Shadow attributes it is visible that there is one activated (even when for this feature the settings seem not sufficient to do much). When changing Blur to '0' an ellipse below the shape can be seen where the 'shadow' is in LO without CairoSDPR. Also changing Transparency to '0' makes it appear stronger.
It's in the right place and shows that in principle the transformation for the shadow used 'works'. Switching off LineStyle in Line shows that that ellipse is created by the outline of the shape, not it's content. Changing Area e.g. to 'color' also makes the fill appear.
Thus my best guess is that whatever that feature does it just fails for bitmap fill. Does anyone reading here know more, e.g. who did that feature? Seems that extracting the geometric content is done wrong/incomplete for the fill bitmap case here - similar to fill color it should probably create/use something like a 'evereywhere-black-where-not-transparent' thing for bitmap fill - which should be done using a ColorModifier Primitive...

Thus: If someone knows more about this feature please add the commit and the author to cc for this task.