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.
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.
Armin Le Grand (allotropia) committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a3e36aaf5fcd7489f802913e93c200f3cde8492d 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: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.