Replace index-based loops with range-based for loops in baseprocessor3d.cxx
and zbufferprocessor3d.cxx. This improves code readability and reduces the
risk of off-by-one errors. The change is purely refactoring: behavior and
output remain unchanged.
Change-Id: I5d30babac3a0fa5fdcca214e66481862a165d7c7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202301
Tested-by: Jenkins
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
This allows setting/using DrawModeFlags system-independent
(or: renderer-independent). Changing and applying to a
PrmitiveRenderer will apply that (if needed) to the target
renderer.
Change-Id: Id95d018f95d1b2ff065da5e4d05ba385b22cdbb0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188704
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
These will never compare with tolerance (the zero is a special case
in rtl_math_approxEqual used internally), so the calls like those
don't do what they appear to do in these cases.
Change-Id: I495ac92b7f45637e118e4fdc04bb6fad6fff31ab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171391
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Added tooling replaceStart/EndColor to allow simple
transition for code that does not immediately adapt
to multi color gradients. Also added
createColorStepsFromStartEndColor for the same
purpose.
Adapted XGradient to no longer have Start/EndColor
at all, but only use ColorSteps.
Adapted all usages of XGradient to no longer use
Get/Set/Start/EndColor, but access the ColorSteps
instead.
Replaced quite some XGradient constructors that
used XGradient() as Start/EndColor since this is
already the default.
Adapted ColorBlending to black AKA Start/EndIntens
in XGradient to work now on all ColorSteps in the
required linearly-scaled manner.
UNO API changes:
Added com::sun::star::awt::ColorStep as basic data
element that holds a pair of Offset and Color.
Added com::sun::star::awt::ColorStepSequence to
handle an array of sorted entries.
Added com::sun::star::awt::Gradient2 derived from
com::sun::star::awt::Gradient, extended by the
needed com::sun::star::awt::ColorStepSequence.
Added MID_GRADIENT_COLORSTEPSEQUENCE to UNO API
to provide access to ColorSteps directly.
Adapted XFillGradientItem::QueryValue/PutValue to
make use of new UNO API data structures. To do so,
added tooling methods for data transition:
- fillColorStepSequenceFromColorSteps
- fillGradient2FromXGradient
- fillColorStepsFromAny
- fillXGradientFromAny
and adapted
- case '0' (all data)
- MID_FILLGRADIENT
- MID_GRADIENT_COLORSTEPSEQUENCE
- MID_GRADIENT_START/ENDCOLOR
to make use of these.
Tested usage of these in the office.
Renamed from GradientStep to GradientStop after
discussions with members on the list to make this
closer related to other norms/definitions.
Also renamed classes and class members to better
reflect to GradientStop, so grepping/finding will
be easier (e.g. 'Color' just exists pretty often,
but 'StopColor' is more precise).
Changed the used UNO API class for reprsenting the
Color to better reflect to ranges [0.0 .. 1.0] and
usage of RGB.
Change-Id: I1eeb3e97e81d6785967615d1ff256551fc3b882d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148849
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Move GradientSteps data to GeoTexSvxGradient and adapt
interfaces. Also move tooling to more isolated place
in gradienttools in basegfx.
Keep everything still compatible, the work will be now
to adapt all six different derivations of
GeoTexSvxGradient to make use of the evtl. given
GradientSteps.
Change-Id: Iaa212763c603d46de0a94b1b203b979bb7ce359d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147050
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
MCGR stands for MultiColorGRadient. This change allows/
prepares adding multiple color steps to gradient rendering.
This is preparation work to allow rendering MCGRs in the
future. All places are adapted in a way that currently
no change of behaviour will happen. It will be the base
to get MCGR rendering/decompose for Primitives and our
internal/existing gradients working.
Change-Id: I28bbd7d10b8670042343ada2a66b5909d3d31bbd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146748
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
...where a signed and an unsigned value are compared, and the signed value has
just been proven to be non-negative here
Change-Id: I20600d61a5d59d739bc1bee838c0038e4611aec2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134875
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Rather than make all the BasePrimitive2D classes bear the cost of being an UNO
object, we just wrap the top level BasePrimitive2D in this class when we need
to pass them over UNO.
This reduces the locking overhead when doing normal drawinglayer operations,
and reduces the size of drawinglayer objects and the cost of initialising
them, which shaves 5% off the load/display time of a large barchart.
Add new drawinglayer::convertPrimitive2DContainerToBitmapEx utility
method to avoid needing to convert to Sequence<XPrimitive2D>
Change-Id: I553eaa4c16ba016b098cb21f6c55f5008f0d9b53
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126487
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
when creating charts, by using a
Primitive2DContainer&&
parameter in the GroupPrimitive2D constructor, which forces the call
sites to pass a temporary, and at most call sites, we can std::move in
an existing local variable.
Change-Id: I531970918800c6832ab606b5a4ff5fd2d47ccf5b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121844
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Remove dynamic_cast'ing to Primitive2D, expensive and unnecessary
<quikee[m]> noelgrandin: nobody is using XPrimtive that is not
derived from BasePrimitive2D in an extension ... mainly as it is
not even possible
Change-Id: I68224021f0fbc35fe2a973198ba78d2b41ea172d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120417
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
They are basically the same thing, but alpha is the preferred term
these days.
Also improve the mixing algorithm,
1 - opacity
is
255 - opacity
not
256 - opacity
since the range of sal_uInt8 is 0..255
Change-Id: I8788ac79285ab25c8d322b05817dffd3745fd699
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108963
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Add attribute for the blur radius and get function.
give more range for the shadow depends on the size of the blur radius.
update the blur radius to be imported in Hmm and the test function.
Change-Id: I32faaf02884d9a6b2f11a9033178b3b6bb419580
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95388
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
...where the get member function is defined on a std::__shared_ptr base class,
so loplugin:simplifypointertobool used to miss those until now. (While e.g.
using libc++ on macOS found those cases.)
366d08f2f6 "new loplugin:simplifypointertobool"
was mistaken in breaking isSmartPointerType(const clang::Type* t) out of
isSmartPointerType(const Expr* e); c874294ad9 "Fix
detection of std::unique_ptr/shared_ptr in loplugin:redundantpointerops" had
introduced that indivisible two-step algorithm on purpose.
The amount of additional hits (on Linux) apparently asked for turning
loplugin:simplifypointertobool into a rewriting plugin. Which in turn showed
that the naive adivce to just "drop the get()" is not sufficient in places that
are not contextually converted to bool, as those places need to be wrapped in a
bool(...) functional cast now. If the expression was already wrapped in
parentheses, those could be reused as part of the functional cast, but
implementing that showed that such cases are not yet found at all by the
existing loplugin:simplifypointertobool. Lets leave that TODO for another
commit.
Besides the changes to compilerplugins/ itself, this change has been generated
fully automatically with the rewriting plugin on Linux.
Change-Id: I83107d6f634fc9ac232986f49044d7017df83e2a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94888
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
Remove the following settings:
QuadraticFormControlRenderLimit
Quadratic3DRenderLimit
RenderSimpleTextDirect
RenderDecoratedTextDirect
SnapHorVerLinesToDiscrete
which have no way to be set from the user interface.
Change-Id: Ie96531425f5ba6021ade4f247b18b99092fd7e5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92275
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I0968cfd6a94c20e6b0d324f068ca658d7d5c0296
Reviewed-on: https://gerrit.libreoffice.org/83294
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
detect static variables that can be made const.
Thanks to mike kaganski for suggesting this.
Here I introduce a new plugin feature - using markers
in nearby comments to disable the plugin for specific
vars.
Some of this stuff was old debugging code. I removed the stuff
that was older than 5 years.
Change-Id: I6ec7742a7fdadf28fd128b592fcdf6da8257585c
Reviewed-on: https://gerrit.libreoffice.org/68807
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Dmitriy Usov