Bug 151081 - Rotated metafile looses rotation of gradient in presentation mode and in export
Summary: Rotated metafile looses rotation of gradient in presentation mode and in export
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
(earliest affected)
Hardware: All All
: medium normal
Assignee: Armin Le Grand
Whiteboard: target:7.5.0
Depends on:
Reported: 2022-09-20 11:10 UTC by Armin Le Grand
Modified: 2022-10-10 08:18 UTC (History)
0 users

See Also:
Crash report or crash signature:

Original with gradient, metafile, and rotated metafile (12.09 KB, application/vnd.oasis.opendocument.presentation)
2022-09-20 11:10 UTC, Armin Le Grand

Note You need to log in before you can comment on or make changes to this bug.
Description Armin Le Grand 2022-09-20 11:10:59 UTC
Created attachment 182569 [details]
Original with gradient, metafile, and rotated metafile

This is a regression to #i121185# as described in drawinglayer/source/processor2d/vclmetafileprocessor2d.cxx. Please see https://bz.apache.org/ooo/show_bug.cgi?id=121185 for the original (before fixed) task.

To reproduce:
1. Create a shape in a presentation and fill it with a linear gradient.
2. Convert the shape to metafile.
3. Rotate the metafile. Notice, that the gradient is rotated too.
4. Switch to presentation mode. Notice, that the gradient is not rotated.

Adding testfile from that task here, too.
Comment 1 Armin Le Grand 2022-09-20 11:19:30 UTC
Reason is the shortcut in VclPixelProcessor2D::processFillGradientPrimitive2D, introduced in 20c09d351ee060bdde13d92d2bf86dd998cdb0cb.

Please refer to comments for #i121185# in VclMetafileProcessor2D::processPolyPolygonGradientPrimitive2D, too.

Using the Primitive decomposition we *can* rotate/shear (freely translate in general) the gradient statically with any object. This *is* used e.g. with Metafiles as graphic information. To fix this regression, a test and usage of regular primitive decomposition is needed. That test has to detect rotation/shear/mirror in the current transformation which is part of the definition of the graphic content. Or - the other way around - that fallback is only allowed when only translation  and scale are used.

This ability of the Primitives is also the potential future fix for the compatibility problem with MS formats that do rotate the gradient with the shape (see e.g. tdf#34551): Historically VCL is/was not capable of doing that, but Primitives are - by definition. Unfortunately using the rotation attribue of the old gradien definitions is no help/solution here either since the BoundRange of the geometry is historically used to define the area that gets filled with the gradient (you can see that when interactively rotating a LinearGradient filled object) - that can not be matched.

It is also the preparation for the requested feature to rotate he content of objects in general with the object, not only the gradients.

I appreciate and see the need to draw gradients faster, but there is are reasons to do it using primitives. Unfortunately ongoing impls in GDI also do not support that, probably mainly due to original GDI not doing so. To really support faster paint of gradients (as long as we do not have system-specific renderers) a GDI method handing over all parameters of the gradient would work: The fallback could use the 'old' stuff, a new implementation could use texure-mapping based things - the old gradient definitions *can* be dismantled to a point where you get a RGB for each X/Y coordinate, this is used in the 3D renderer already and can be used/copied. The better long-term way would be to use system-specific renderers.

To fix his for now I will add another needed fallback VclPixelProcessor2D::processFillGradientPrimitive2D to use the regular primitive decomposition.
Comment 2 Commit Notification 2022-09-21 07:48:35 UTC
Armin Le Grand (allotropia) committed a patch related to this issue.
It has been pushed to "master":


tdf#151081 render rotated gradients correctly

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:

Affected users are encouraged to test the fix and report feedback.