NOT REPRODUCED..

ENVIRONMENT:LibreOfficeDev-7.4.0.0.alpha0_2022-01-23-x86_64 

VERSION: TESTED IN ---Linux Mint 21 Cinnamon

Created attachment 182378 [details]
FOR THIS IMAGE :BEFORE EXPORT TO PDF

Created attachment 182379 [details]
FOR THIS IMAGE:AFTER EXPORT TO PDF

(In reply to Manikandan C from comment #1)
> NOT REPRODUCED..

Hi Manikandan, why do you say this is not reproducible?

The second screenshot you posted (attachment 182379 [details]) clearly shows the error in gradient after being exported to PDF. Notice the circular lines that are visible in the PDF, which are not visible in Impress (see your attachment 182378 [details]).

Confirm with Version: 7.5.0.0.alpha0+ / LibreOffice Community
Build ID: e46f9cc4b506c325cbe1060777bbc81fd1630f49
CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded

and Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)

Created attachment 182570 [details]
Sample ODP file

Here's a sample ODP file with a shape with radial gradient.

Created attachment 182571 [details]
Sample PDF file

Here's the PDF generated from the ODP file above.

Hi Armin, given your recent work on a gradient-related patch, maybe you could give your opinion on this one as well.

Hi Rafael,
I took a look:

Export starts by recording a Metafle (unfortunately still the base for PDF export, no Primitive processor for that). At drawinglayer/source/processor2d/vclmetafileprocessor2d.cxx:2004 in processPolyPolygonGradientPrimitive2D the fallback to the 'old' vcl-paint is taken.

The PDF exporter in vcl/source/gdi/pdfwriter_impl2.cxx:681 in playMetafile sees the created MetaCommentAction containing the gradient as "XPATHFILL_SEQ_BEGIN", but that is no used (here are two stacked XPATHFILL_SEQ_BEGIN/XPATHFILL_SEQ_END pairs here created from he old former paint). This is no used.

It continues to the 2nd pair at ln 555 and detects the comment as MetaGradientExAction. There ln 581 implWriteGradient is taken. That creates the MetafileAcions temporarily (AddGradientActions) and plays them inside the PDFWriterImpl using playMetafile.

Gradient::AddGradientActions uses Gradient::DrawComplexGradientToMetafile. That (old) stuff creates a stepped bunch of 'donuts'. These get written as filled polyPolygons to the PDF.

What we see is not directly an error, but bad quality of the 'overlapping' of those 'donuts' building the gradient.

The gradient cannot directly be exported to PDF since our old gradient definitions cannot be matched to PDF definitions, so this geometric representation is created and exported.

For non-transparent gradients it is possible (and simpler) to not use 'donuts' but the whole stack of overlapping ellipses.

We could try to balance around with the sizes of the 'donuts' to get a better overlapping - problem is the AntiAliased paint in the PDF renderer(s) here - it sees only a bunch of 'donuts' and does not know that it's supposed to be a gradient. We did that a lot - experience tells that his will probably create another problem somewhere else (Gradient::AddGradientActions is no only used for PDF export).

It's ugly but there is unfortunately no simple, good solution. A bigger redesign would be needed to generally solve that stuff. When debugging you can see many places where fixes/changes were already done, too - very dangerous and unstable (unfortunately).

Sorry, no simple fix available...

One more note:

I checked how it looks when forcing to use just the primitive decompose in VclMetafileProcessor2D::processPolyPolygonGradientPrimitive2D - that's much better. That was used (and could be) before the shortcut introduced by 20c09d351ee060bdde13d92d2bf86dd998cdb0cb (as already mentioned in https://bugs.documentfoundation.org/show_bug.cgi?id=151081#c1). That led to many problems. It's intentions to speedup gradient paint are good, but it had many side-effects, which we seem to have to fix now one after the other...

Thus, another simple fix for this would be:

--
index 8e221affe978..8ebc653f580f 100644
--- a/drawinglayer/source/processor2d/vclmetafileprocessor2d.cxx
+++ b/drawinglayer/source/processor2d/vclmetafileprocessor2d.cxx
@@ -1938,6 +1938,13 @@ void VclMetafileProcessor2D::processPolyPolygonGradientPrimitive2D(
         return;
     }
 
+    // tdf#150551 for PDF export, use the decomposition for better gradient visualization
+    if(nullptr != mpPDFExtOutDevData)
+    {
+        process(rGradientCandidate);
+        return;
+    }
+
     basegfx::B2DPolyPolygon aLocalPolyPolygon(rGradientCandidate.getB2DPolyPolygon());
 
     if (aLocalPolyPolygon.getB2DRange() != rGradientCandidate.getDefinitionRange())
--

That uses the state before 20c09d351ee060bdde13d92d2bf86dd998cdb0cb for PDF exports, but keeps the fallback to old VCL rendering for other cases.

As I explained in https://bugs.documentfoundation.org/show_bug.cgi?id=151081#c1 I would prefer a different approach to speedup gradient paint for pixel targets.

Created attachment 182601 [details]
Sample PDF File (with patch applied)

(In reply to Armin Le Grand from comment #11)
> Thus, another simple fix for this would be:

Hi Armin... here's the PDF file generated with the patch you proposed.

It is not a perfect fix, since one can still see the donuts. However it is a lot better than the current state.

Since a definitive fix would be too complicated, maybe we could go with your proposed patch for the time being. What do you think?

Why not, it's on gerrit now:

https://gerrit.libreoffice.org/c/core/+/140354

This puts it at least to the state before the change leaded to this regression. To do more I would need to know more why the two ::processPolyPolygonGradientPrimitive2D methods were added.

The one at VclPixelProcessor2D only replaces the case that start/end color are the same, but not even calls older (faster?) vcl methods, so I see no gain there, but may overlook something. BTW that useful check/optimization should go to PolyPolygonGradientPrimitive2D::create2DDecomposition, so all renderers (now and in the future) would use that optimization. In the end the decomposition of the resulting create2DDecomposition creates a single polygon, but it's embedded in a MaskPrimitive2D in PolyPolygonGradientPrimitive2D::create2DDecomposition, so the optimization in VclPixelProcessor2D::processPolyPolygonGradientPrimitive2D is better here, but - as explained - will only have effect in VclPixelProcessor2D since not added to the decompose.

The one at VclMetafileProcessor2D should not be time-critical at all since it's for creating metafiles. It leads to regressions, as we see...

Armin Le Grand (allotropia) committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/2914316bcffc890887ca577d2753149c07005815

tdf#150551 for PDF export, use the decomposition

It will be available in 7.5.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.

*** Bug 73526 has been marked as a duplicate of this bug. ***