We already did some improvements, but I wanted to clean
this up somewhat. Reason for the needed corrections was
in principle the sqrt()-based general calculation of
the HoldTime in the default implementation of
calculateCombinedHoldCyclesInSeconds. The original idea
was to hold huge data shorter due to memory constraints.
To solve that we added an adapted version to
CairoPixelProcessor2D.
With lessons learned I decided to remove that and
provide a revised general implementation based on linear
scaling of the HoldTime. Based on assuming the seen
huge Bitmap and estimating 20min for it, just create a
factor and multiply with SizeInBytes.
I checked that and it works as intended. It will spare
us from this problem re-occurring with future SDPRs.
NOTE: This still keeps the CairoSDPR-specific avoiding
of buffering of small Bitmaps when these are available
from Bitmap directly. This stays useful and is
Cairo-specific.
Signed-off-by: Armin Le Grand (collabora) <Armin.LeGrand@collabora.com>
Change-Id: I30c7361c6fbfaf0be90be353091cbaf831db5cd2
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/2005
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit a3d3ae5e931a04ff5718382ccffe9f16de336a42)
(cherry picked from commit 7550c6ea0bb82f7574e4b974f8d24bd1662a878b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205991
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
All the changes should go through BColorStops interface and not
directly.
Change-Id: I4c6dd42f8d6b6c43cdcf9d53557ccb12f8d0507c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195386
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
Detect where created when a RGBA gradient could be
used directly and create a primitive representing
that, a PolyPolygonRGBAGradientPrimitive2D.
That primitive decomposes to what was created before,
so no primitive renderer has to be touched, all will
work as before.
NOTE: That helper primitive just holds references to
what would be created anyways, so one depth step
added but not really any additional data.
This is the 1st step for direct support, the 2nd is
to then detect and use that primitive in SDPR
implementations directly.
Change-Id: I4f247636ce58a8a1fd1e0df32dabed0d6cc10d0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170527
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Up to now that genereal buffering mechanism used
typeid.*hash_code to identify the class. As we
have learned this is not safe. Thus I changed it
to use enum'ed SystemDependentDataType definitions
Change-Id: I803912ec419290db1d40bae0bc41364fad64cbfd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170385
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Added and corrected quite some stuff to this basic
construct provided by Caolan (thanks again!). No
detailed descriptions here, but it's getting more
complete and faster.
May contain errors and is primitive-complete in the
sense that all gets rendered, but some basic stuff
that should be directly supported is still missing,
e.g. text rendering.
Adding this to allow people to check it out (speed)
also since it's not yet used as default in master,
so it's safe and also safes the changes publically.
To test it, use TEST_SYSTEM_PRIMITIVE_RENDERER as
set EnvVar in linux systems.
Change-Id: I25f795c9ea4ad4f3b99591304f8803dffa499436
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168911
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
As part of the efforts in #157664 to remove redundant definitions of
operator!=, to upgrade the codebase to C++20, this commit removes the
remaining definitions in the basegfx module.
Change-Id: I19f2b9ddf42185435313445c8395a851030e2149
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165199
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Comparing with zero is simple - the implementation of basegfx::fTools::moreOrEqual
calls rtl_math_approxEqual eventually, which special-zases zero.
Change-Id: I62f10f63f103d91a201dfeb20e5b3f9010f377c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164526
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This is needed because the module dependencies are an issues if
the conversion is done in basegfx. The bigger issue will come when
the ComplexColor conversion will be done as basegfx can't depend on
docmodel because of circular dependencies.
The BGradient is also more suitable for docmodel anyway as the
previously it was part of the model and is not a basic (gfx)
type - however this doesn't move the whole BGradient into docmodel
yet.
Change-Id: Id91ce52232f89f00e09b451c13da36e2854ae14b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155674
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Rendering of stepped gradients uses a method that doesn't take the
color from a cut point, but before or after respectively. For example,
for StepCount 4, the colors at relative positions 0, 1/3, 2/3 and 1
are used. So sections are 'start color', '1/3 color', '2/3 color' and
'end color'. The output to OOXML now uses the same method. That way
rendering in a produced pptx-file is the same as in the original
odp-file. Since OOXML has nothing similar to StepCount, it is an export
only problem.
A second problem comes from the cuddle with StepCount in Gradient
struct in API and FillStepCount in shape property set. The
draw:gradient-stop-count attribute in ODF belongs to the graphic style
of the shape. The gradient definition itself in the <draw:gradient>
element has nothing about step count. When a file is opened, it can be
that the StepCount component in the Gradient struct still has the
default value 0, but the FillStepCount property has the correct value
of the shape.
The Gradient struct in the API should not have a component StepCount
to be compatible with ODF. But the API is published and changing that
struct is far-reaching in the code. So the fix here is not a general
solution but solves the problem for export to OOXML by reading the
FillStepCount property while exporting.
Change-Id: Ie1cafe6bdda7c4d74b05f279f0d8212ff67ecc92
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153154
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
While synchronizing color and transparency gradients two new sequences
are generated. In case the last offsets where different, the remaining
stops where not copied to the new sequence and thus they had different
sizes which triggered an assert in oox/source/export/drawingml.cxx.
Change-Id: I446f8cfafb23735f06ad4e05eee8c922141b864d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153063
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Unfortunately SVG export is based on metafiles and thus there
is (in principle) no way to get the BGradient/ColorStop/MCGR
data transfered as needed. For that, using UNO API to read the
model or using B2DPrimitives would help - as is better for the
export respectively.
Since there is not the time to re-design SVG export I added
this 'compromize' as a fix. It gets the needed data transported
over the metafile (that part is the compromize). It then
exports the MCGR data to SVG (at least - as was already there -
if it's a linear/axial gradient). This happens now with all
Gradient Stops when there is a MCGR gradient. That part is/will
hopefully be re-usable if SVG export gets redesigned.
I also added a handling for StepCount feature, so when used (in
LO, others do not have that) 'hard' color stops get generated
to make the gradient look identical for SVG export.
Had to make adding of that extra-information in metafiles
dependent on exporting really to SVG. There are 51 cases which
use 'MetaActionType::COMMENT' which would potentially have
to be adapted.
Also added code to solve the problem for TransparencePrimitive2D
at VclMetafileProcessor2D::processTransparencePrimitive2D. This
will now - also only for SVG export - directly create the needed
MetaFloatTransparentAction and add additional MCGR information.
This will be used on SVG export to write a 'Mask' as was done
before. This is now capable of creating fill MCGR-Masks in
the sense that any number of TransparencyStops will be supported.
Change-Id: Ic6d022714eae96b8fbc09e60652851ac5799b757
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152623
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
When exporting a shape with an axial gradient fill to OOXML, it is
converted to a linear gradient with multiple color stops. Versions
before MCGR had recreated it as axial gradient on import from OOXML.
But now LO is able to handle multiple color stops and so the linear
gradient from OOXML is imported as linear gradient in LO.
When such file is then written as ODF, the multiple color stops are
in elements in extended namespace and versions before MCGR do not
understand them. They show only the first and last color (which are
equal) and the gradient is lost.
With this patch LO converts the linear gradient back to an axial gradient
on export to ODF. The exported axial gradient is rendered in a version
with MCGR same as the linear gradient when opening the OOXML file. The
difference is, that versions without MCGR now render an axial gradient
with two colors.
Change-Id: I2b416b4cdca75d8327107a4f259d63c2e6e97ac3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152574
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
Due to tdf#155362 I added code to be able in case we
would need it to convert a BGradient using added
tooling from having offsets in the GradientSteps
and no border to adapted GradientSteps and border.
This is preferrable due to our GradientStyle_RECT
(and GradientStyle_ELLIPTICAL too) use that 'non-
linear' paint aka move-two-pixels-inside, someone
else called it 'frame-paint'. This does not bode
well with the border being applied 'linear' at the
same time (argh). Thus - while in principle all is
correct when re-importing a GradientStyle_RECT
with a border after export to pptx, it looks
slightly better ('correcter') wen doing so. That is
because when being able to and restoring a border
at least that border part *is* applied linearly.
I took the chance to further apply tooling, move
it to classes involved and instead of awt::Gradient2
use more basegfx::BGradient since it can and does
host tooling. This is also a preparation to be
able to adapt (restore) border in case of turn-
around in ODF where the importing instance is before
MCGR existance and has to handle Start/EndColor.
Needed to take more care with using BGradient instead
of awt::Gradient2 for initialization, also better
dividing/organization of tooling, already preparation
to use for other purposes.
Change-Id: I2d3a4240a5ac6fff9211b46642ee80366dc09e3d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152194
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Added code to make WriteGradientFill directly use the
available BGradient implementation. The goal is to
never directly work on awt::Gradient2, but use
BGradient & it's tooling methods.
Added constructors and tooling to BGradient and
BColorStops to make that easier (single line
conversions between uno::Any, basesgfx classes
and awt:: incarnations). Directly handle uno::Any
and awt:: classes, changed stuff to make use of
this.
Change-Id: I083a323b9efee8ca4f3becb2966aac0a294b9a60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151842
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Adapted handling of 'border' argument from our gradients
for oox export, so that it looks the same.
Also added quite some cases to peserve in-between
GradientStops for current UI implementations to be
able to edit the gradients as usual without losing
the in-between GradientStops.
While we will not be able to modify these, we are
at least able to modify all the other gradient
attributes, including start/endColor.
Done this for TransparencyGradients, too.
Also moved more stuff to the gradient tooling in
basegfx.
Change-Id: I6e94011bbf3715baa1401ab97e5b59811298342f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150577
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
This is a 1st version and might need more fine-tuning,
so it is still 'hidden' behind the MCGR_TEST env var
being set (as the import is, too).
Still, when used, it can now import a MCGR with
transparence and export it again. I will now do extended
testing/experimenting, fine-tuning where needed and
prepare final change/drive forward.
The current state in master should not be changed as
long as the mentioned env var is not set, but this
will need to be checked, too, due to changes to the
export api in oox.
Corrected an error in GetAlphaFromTransparenceGradient
method(s), css::rendering::RGBColor is [0.0 .. 1.0]
Corercted an error in WriteSolidFill where transparence
gradient gets checked. This should really check if
TrGr is used, but only checks for 'empty/unused'
color instead (assuming COL_BLACK is 'unused').
All usages of GetAlphaFromTransparenceGradient should
be checked and adapted.
Change-Id: If59d7a06b9207e2efe9e71f3f8ddeca4476408f3
Change-Id: If97f8abdd0e1597aa1fd865b7e884e06a22b71f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150391
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
The colors of a ColorStopRange can be equal in case of
hit *and* miss, so in both cases. I moved it to the
common computation part. Prev version worked and did
no harm, but unnecessary color interpolations for equal
colors.
Change-Id: I19031f1021ee5955b48da5c0d8e3a03cb9512ebf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150046
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Moved the Gradient intensity handling to tooling since
it is also needed for TransparencyGradients. Added
missing use of GradientStepCount for transparency.
Change-Id: I63ae6683fa0131be7faadc8572e19f5c43bf27e3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149957
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Xisco Fauli