Make getSystemDependantDataInternal (with "a") in
getSystemDependentDataInternal (with "e") to have it
coherent with addOrReplaceSystemDependentDataInternal and the class
addOrReplaceSystemDependentDataInternal
Change-Id: Id56d54c0981752f09387d43a3eb33fab81ccd5c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209484
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
The patch adds a color interpolation in the HSL color model to the
BColor tools and extends the 'Duplicate' dialog to include these new
color interpolations.
This patch also solves bug tdf#173142.
Change-Id: Ie7f15d65f20b6a8d116c2ac03a57540e6be25ae1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209366
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
translate/scale/rotate/shearX/shearY each used to build a
temporary B2DHomMatrix in the obvious sparse form and run the
generic doMulMatrix to combine it with *this, which multiplies and
adds a lot of zeros for every call. Make it faster by applying each
transform directly to the six stored cells instead.
Also unroll doMulMatrix itself (caching the six old values in
locals since the result overwrites them) and unroll the isIdentity
/ identity loops.
Using the micro-bench the speedup can be 50% for translate and
shear operations. In practice this will not have much measurable
effect (it could accumulate as B2DHomMatrix is used a lot for
rendering) but as the code is also more straight forward it is
worth merging.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: If13d91d4c7353be4e4433d8d8bb7f40866578a5b
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/2755
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 3db39371454fa7de994dbc9b214668a4818ed357)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205801
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Use the Arvo method for B2DRange::transform(), which computes the
new AABB directly from matrix element signs instead of transforming
all 4 corners. This reduces multiplications from 16 to 8 and
eliminates temporary B2DPoint construction and expand() branching.
Benchmark shows about 2.8x speedup.
For polygon transform, extract matrix values once before the loop
instead of calling rMatrix.get() per point. Applies to both the
simple point path and the Bezier control vector path.
Benchmark shows about 1.45x speedup.
Change-Id: I56c1b415fd59dc24a5bec515d952064dee46403e
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/2870
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 6d682b4c9ae3e177a97be68ebeb7383c0148601d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205802
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
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
EMF+ custom line caps (and any caller that supplies a notched arrow
polygon) left a visible triangular gap between the line shaft and the
arrowhead: createAreaGeometryForLineStartEnd shortened the line by the
polygon's full Y extent (out to the back wings) even though the
centerline exits the polygon interior earlier, at the back-of-cap notch.
Detect that case by computing the X=0 crossings of the transformed
arrow polygon and reducing the consumed line length to the first
crossing above Y=0 when the centerline is interior at Y=0+. Simple
convex caps (triangles, squares, etc.) are unaffected because their
centerline is interior all the way to the polygon back.
Includes basegfx unit tests covering both the notched-arrow case (line
must stop at the notch, not the wings) and a simple triangle (line
still consumed for full polygon length).
Signed-off-by: Andras Timar <andras.timar@collabora.com>
Change-Id: I68618c7b2ac7cb5de0a2311d642478218de92652
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/2208
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit fc0881223c9c5a01fb07aeb73bdc849caf981fbc)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205088
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
when it gets complex the solvePolygonOperationOr() algorithm
becomes rather expensive. But we can do much better in this
case since we know we only have rectangles.
Change-Id: I2fdfce7925e843e25f11890dac2c96ce21f3be67
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202261
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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
in the unlikely case that fLength was 0f, then while we might (float)
divide by it and get some junk value, we multiply that by fLength of 0f
anyway so it would be a no-op
cid#1664878 Division or modulo by float zero
cid#1664879 Division or modulo by float zero
cid#1659880 Division or modulo by float zero
Change-Id: I8a0bf9f04975af252e59f9e15247871f915c8037
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194829
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
After recent commit 851fb75779
recheck these directories in include/ again
to test drive the new --headersfwd mode of bin/find-unneeded-includes
Change-Id: I0ede437c4f9958cd98210ed1760a5b98ea8bd1ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192377
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
and
cid#1659880 Division or modulo by float zero
drop the default arguments, they are always explicitly set
except for one single case.
Change-Id: I1fce4e7f6ff5c9421c40628e0b6a1e291650e51c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189862
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
which shows up heavily on this profile. In this case we don't
need perfection and we can use a fast approximation for std::pow.
Thanks to the binary representation of float numbers, this new
code reduces to some basic bit-twiddling.
Change-Id: I064588f65cf8f5973ba45545fba9c5fe66500e37
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184602
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...so it can be used with std::sort in impSolve() (further down in
basegfx/source/polygon/b2dpolypolygoncutter.cxx). At least on macOS with a
LLVM 20 trunk libc++ in hardened mode, JunitTest_sfx2_complex failed with
> ~/llvm/inst/bin/../include/c++/v1/__debug_utils/strict_weak_ordering_check.h:59: assertion __comp(*(__first + __a), *(__first + __b)) failed: Your comparator is not a valid strict-weak ordering
To simplify the new implementation of struct SN operator <, add a B2DPoint
operator <=> (but whose implementation would cause
> In file included from /home/tdf/lode/jenkins/workspace/android_arm/basegfx/source/curve/b2dbeziertools.cxx:21:
> In file included from /home/tdf/lode/jenkins/workspace/android_arm/include/basegfx/curve/b2dcubicbezier.hxx:22:
> /home/tdf/lode/jenkins/workspace/android_arm/include/basegfx/point/b2dpoint.hxx:129:41: error: invalid operands to binary expression ('tuple<const double &, const double &>' and 'tuple<const double &, const double &>')
> { return std::tie(a.mnX, a.mnY) <=> std::tie(b.mnX, b.mnY); }
> ~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~
etc. on Android with NDK 23.2, see
<https://ci.libreoffice.org/job/gerrit_android_arm/43174/>, so work around that
in the implementation for now).
Change-Id: I9f46d39dc9e9024fe9ac59413c44e49642282c8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175622
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Andrea Gelmini