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>
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
If we have a really 'big' pixel-based graphic the cost for creating
the mip-map entries is high. If that is the case, force keeping this
entry alive and not getting flushed by using a large number of
seconds. In that case the local MipMap is more important than the
memory kept allocated for fast repaints.
To detect 'big' graphics, compare to an assumed ScreenSize (may also
be fetched from real screen if needed). To react, create a buffer
residing time of one hour (increase if needed).
NOTE: This will increase MemoryFootPrint if isCairoCompatible
is false by holding the local cairo_surface_t in CairoSurfaceHelper
longer than before.
Change-Id: I1cf726f00d459bc0cb19bb1d202e64e010061426
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/1134
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 2e1b0a51a745e615ed7e2f22666cc4aa4e005451)
(cherry picked from commit c2c58c177ae822906fe2c558546851643fe54247)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205988
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
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>
Fixes warnings like this one seen in a clang-cl (21.1.8)
build on Windows:
C:/Users/mwegh/development/git/libreoffice-WORKTREE/include\basegfx/utils/systemdependentdata.hxx(45,16): warning: 'dllimport' attribute only applies to functions, variables, classes, and Objective-C
interfaces [-Wignored-attributes]
45 | enum class BASEGFX_DLLPUBLIC SDD_Type : sal_uInt16 {
| ^
C:/Users/mwegh/development/git/libreoffice-WORKTREE/include\basegfx/basegfxdllapi.h(33,27):: note: expanded from macro 'BASEGFX_DLLPUBLIC'
33 | #define BASEGFX_DLLPUBLIC SAL_DLLPUBLIC_IMPORT
| ^
C:/Users/mwegh/development/git/libreoffice-WORKTREE/include\sal/types.h(210,47): note: expanded from macro 'SAL_DLLPUBLIC_IMPORT'
210 | # define SAL_DLLPUBLIC_IMPORT __declspec(dllimport)
| ^
and
In file included from C:/Users/mwegh/development/git/libreoffice-WORKTREE/oox/source/drawingml/diagram/datamodelcontext.cxx:20:
In file included from C:/Users/mwegh/development/git/libreoffice-WORKTREE/oox/source/drawingml/diagram\datamodelcontext.hxx:24:
In file included from C:/Users/mwegh/development/git/libreoffice-WORKTREE/oox/source/drawingml/diagram\datamodel_oox.hxx:29:
In file included from C:/Users/mwegh/development/git/libreoffice-WORKTREE/include\svx/diagram/datamodel_svx.hxx:30:
C:/Users/mwegh/development/git/libreoffice-WORKTREE/include\svx/diagram/DomMapFlag.hxx(28,12): warning: 'dllimport' attribute only applies to functions, variables, classes, and Objective-C interfaces
[-Wignored-attributes]
28 | enum class SVXCORE_DLLPUBLIC DomMapFlag : sal_uInt16
| ^
C:/Users/mwegh/development/git/libreoffice-WORKTREE/include\svx/svxdllapi.h(35,27): note: expanded from macro 'SVXCORE_DLLPUBLIC'
35 | #define SVXCORE_DLLPUBLIC SAL_DLLPUBLIC_IMPORT
| ^
C:/Users/mwegh/development/git/libreoffice-WORKTREE/include\sal/types.h(210,47): note: expanded from macro 'SAL_DLLPUBLIC_IMPORT'
210 | # define SAL_DLLPUB[build CXX] oox/source/drawingml/diagram/layoutatomvisitorbase.cxx
LIC_IMPORT __declspec(dllimport)
|
Change-Id: Id472eea3ccb9270e87cfce4e5e6761c566fdbdc0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202144
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
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
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
and
cid#1659754 Variable copied when it could be moved
cid#1659755 Variable copied when it could be moved
cid#1659756 Variable copied when it could be moved
cid#1659766 Variable copied when it could be moved
cid#1659767 Variable copied when it could be moved
cid#1659769 Variable copied when it could be moved
cid#1659770 Variable copied when it could be moved
cid#1659777 Variable copied when it could be moved
cid#1659787 Variable copied when it could be moved
cid#1659790 Variable copied when it could be moved
cid#1659793 Variable copied when it could be moved
cid#1659802 Variable copied when it could be moved
cid#1659818 Variable copied when it could be moved
cid#1659822 Variable copied when it could be moved
cid#1659824 Variable copied when it could be moved
cid#1659825 Variable copied when it could be moved
cid#1659826 Variable copied when it could be moved
cid#1659842 Variable copied when it could be moved
cid#1659849 Variable copied when it could be moved
cid#1659850 Variable copied when it could be moved
Change-Id: I70729aaf6e229518a9a50ac18311286ab5b05b53
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189348
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
...which had been added with 41ab6a5dfa "struct SN
needs a strict weak ordering operator <" and should no longer be necessary
since2b68bf57789714bf79b5bd1fc3e4e9ad586b7c31 "android: Update minimum NDK
version to 27"
Change-Id: I8a2fb01804ed6220bb927175992b4d5015b0d7e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182281
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...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>
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>
There is the complete BColorModifierStack support for
primitives for Bitmaps, e.g. hue/saturation, etc, but
it was slow due to not being buffered, so had to be
re-created often. I changed this to use the common
buffering mechanism to improve this.
Up to now a fallback to use the old Graphic
manipulators for that purpose was in place since this
was faster, but had to be done every time. I have now
changed the priority to using the primitive way to
handle things, but kept the fallback code - just in
case.
Note that the new stuff is faster, but even much faster
when the bitmap is copied and appears multiple times ->
the same buffered instance is used, and SDPRs then use
the system-dependent data buffered at that prepared
data.
Also note that this change does not only speedup
CairoSDPR, but all PrimitiveRenderers, including the
VCL and Metafile ones. In principle everything that
uses BitmapEx::ModifyBitmapEx.
Had a 2nd thought: Only the content Bitmap gets changed,
so for this case we do not need AssociatedAlpha and
watch for it to not have changed. Removed that.
Change-Id: I2ee36cc84bdc1c723aa01f872edbfd1f51e11c2d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170305
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 tdf#147906 to replace expressions like
sqrt(a^2 + b^2) with std::hypot(a, b), to eliminate overflow
errors, this commit performs the changes in certain files.
This also changes the B3DVector::normalize and B2DVector::normalize
methods to have similar behaviour.
Change-Id: I142585cfa594849f06cd06517ad9d40430df2ade
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165555
Tested-by: Hossein <hossein@libreoffice.org>
Reviewed-by: Hossein <hossein@libreoffice.org>
Andrea Gelmini