Age | Commit message (Collapse) | Author |
|
Change-Id: I85cf40e4803b0485bb40349d8e81adc8123666c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151706
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: I20b32e7c272112c6c3d9f7ee0ef59c6d4d006d94
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150020
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
To do this, I re-organized FillGradientPrimitive2D and
how it creates it's decompose. This provides the needed
tooling to also do a more direct rendering in primitive
processors if needed.
The decompose no longer collects the matrices & colors
as a 1st step in a helper data struecture (so I removed
B2DHomMatrixAndBColor). It now uses a lambda function
callback that hands over the matrix & color for each
created step, so you can process it directly, in this
case to create the needed primitives.
NOTE: The decompositions are both tested. There was
createNonOverlappingFill, but also createOverlappingFill
that I am not sure is still used - and if in re-creating
an old, strange XOR-using gradient paint mechanism in
old metafiles (encapsulated with gradient info anyways),
but I converted that and made sure it works.
To do so I forced it to be used in paint. This is not
really usable in paint since we need to paint using AA
(else we would get staircase effects, esp. in new 'hard'
color changes in multi-color gradients) and - as should
be known - same edges painted in AA do *not* add up to
full opacity, but leave behind awful 'jaggies' (e.g.
opacity 0.5 and 0.5 create 0.75 and *not* 1.0). Still
important to have the working geometry creation for this
case.
This already makes the decompose faster, but the main
purpose is to use it as tooling for painting in own
primitive renderers.
Thus processFillGradientPrimitive2D now uses that
instead of using the decomposition by default.
This avoids one level of primitive creation, use
that new FillGradientPrimitive2D tooling to directly
create needed geoemtry & color for getting better
performance (to partially compensate for potentially
more expensive multi color gradients). It then paints
directly using OutputDevice calls.
NOTE: This can also be used in SDPRs as a 1st step
to just directly and rapidly render filled single-
color polygons, but of course there an implementation
using the back-transformations (which are also
adapted for MCGRs aleady and work) will be superior.
Change-Id: I5079f76d6d8fe86007a098614c276447f2bfebce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149456
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
The biggest change here is to allow multiple ColorStops
with the same Offset. That allows to define gradients
with 'hard' color changes at any place using two
ColorStops with the same Offset and different Colors.
This required quite some adaptions, but works well.
Also removed in this context checking for all Colors
being the same to not mix up things. Also works well.
Also changed the need for having Start/EndColors AKA
ColorStops for 0.0 and 1.0 in place, instead 'imply'
the 1st ColorStop to also define the StartColor and
the last one the EndColor. This allows e.g. Gradient
definitions with two GradientStops at the same
Offset e.g. 0.5 with different colors to already
define a full Gradient.
Also added a tooling method to reverse ColorSteps,
which changes the order and mirrors the Offsets
(what even keeps an existing sort valid).
This is useful e.g. for GradientAxial which is the
only one where for decomposition the Gradient had
to be interpreted 'reverse' since it's defined
from center to edge, but for creating correct filled
polygons to represent this the inverse order had to
be used, creating polygons from edge to center.
This led to 'wild' code for this one of six cases
and prevented unifications with the other cases
(also made your brain flip).
Thus I adapted this now to use the reversed
ColorSteps consequently, and the same principle
loops than the other implementations to make things
easier for the future and to use common tooling.
Change-Id: If2943348d17d5b9cd165f4d78f22638a1dff5237
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149208
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
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>
|
|
Change-Id: I8a3245c6a4d687edbc95cf28b2932d80c86a7b65
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135828
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Icf5a3ae47aec43854e669133f3d0c2bace1d942d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135090
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which we can std::move the data around, instead of copying
Change-Id: Id7aaad3970b942599807b7fda73d028f082a0f38
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135089
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
See tdf#42949 for motivation
Change-Id: I916f42c46efa1b6cfd7744a189b79659b2867431
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128196
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Ida2e859165e1698bf1837a6495d6df0f01b4a284
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127339
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This separates the drawinglayer core functionallity into a
separate library, to keep a strict separation what is backend
dependent and what is not. More strict separation can be done
at a later date.
This will make it possible to push part of drawinglayer
(part of processor2d) directly into VCL.
Change-Id: Ibc26580067e50bf20d7cdd37fa0e44eb10200878
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127286
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
follow up to commit 1103727fb24b368419ea0cfd2382560ef6b82f43
Change-Id: I227042f4703f3f4c18a8dc0355f044d2ad7dfb2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126838
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
I have moved the header file to include/vcl/rendercontext as this will
eventually be part of the RenderContext split from OutputDevice.
State and associated enums have also been moved to the vcl namespace. I
have also moved ComplexTextLayoutFlags into the vcl::text namespace.
Change-Id: I0abbf560e75b45a272854b267e948c240cd69091
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121524
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
by passing PrimitiveContainer&& around.
There are lots of place where we were preparing a local variable of type
PrimitiveContainer, and then copying it someplace else, then throwing it
away.
Change-Id: Iacfd983640c9e55da25800ccc01734dfc8b4d64a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122527
Tested-by: Jenkins
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>
|
|
Change-Id: Ie997afa3127fce9fe9de5b0359f54b1890dd6a21
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120558
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Idba40d9816f29c0e4bc4a468b8c0a2cbb74d09d3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119481
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
And fix includes all over the place...
Change-Id: I6e2696bbeeac6ab7467cac70545fa7209aa981a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117528
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I78260d3e6ad8ce96db4353fede18d5e3a6808402
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116400
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I71a15c532ba161d69585bd47631b3a8e2f6ddd66
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115304
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
So that we have fewer cases to deal with when we transition to
32-bit bitmaps.
(*) rename maMask to maAlphaMask, since now it is only being used
for alpha duties.
(*) drop mbAlpha and mbTransparent to simplify state management,
the only thing we need to check for alpha is if maAlphaMask is
non-empty.
Change-Id: I06252e38e950e846a94b4c2ba8ea763be17801fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111679
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id3728ac0011d3deed7e56081e3a854c7fa5336f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113959
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ia9d04447f927e270a55500e7f35723a729bc01dd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113801
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I835c8fcc237ece5cf9d7a3b261645139d022e9b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113652
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I60e61133c305673bb305e41957f5414820c7c358
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112790
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Id6dfae9fb97fbe3fc89b9f2e083d7a3d5c1d36d3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112411
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
By convention, it should be the first include in C/CXX files;
so use of pch should not break that.
Change-Id: Ic329c5f39e8f48ad1778724368e262e48972342b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112123
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Id892e426343746df2f01f4cdc5f470351bdb6a12
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112099
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
I just used ./bin/update_pch.sh
Change-Id: I06a7f36eb4c511b8d6c6477fd87e57f0d9702457
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112097
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ide49c48738ecd537d4eb69390d22807561d3b4e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111828
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I44424081b7f55710c4db7f10d1829de1ae08be76
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111363
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ic4586057346b6de700c1bb6ff4cd759a11bb3e4d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111231
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ia013878ac9c2918d8eaf9aab16b291d8211e708f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110700
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Icdc27fa9ab33a6c5a442760a9491e82000883ef1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110177
Tested-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
and we can drop their factories then
Change-Id: I1e261886dd7700710ba628da4bbeeba65efa1531
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107134
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I3e22c2000da03f6f3345353846213203993aa865
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107192
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I8f3cd05dbd86bd22fd84d767adc44fc2b0c89404
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105468
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I41a204fbc5e2c9b819fb948c5288f8d7b4195489
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103117
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Iaab26ade1109daf732e58a2f3741cc43243e374c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102023
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: If51bf7143116721e8f16272cf8aff797651d5ed1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101880
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: If6683cd134e9bd675ec9b6f9a59fa667ebb41da0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101647
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I786548bef39fa711aabcff32b592b3fdc4a6f9fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101486
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I57a47358d5e4f1e41fc1c89884b7603d8afdc3bd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100646
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I6b3b6ef1530a192f4b6bf87aa9688687063683ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100591
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I32648ae81c4a06f944b70c0cca1694333ec02859
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98916
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I75602277a5a26b012a12f2c4f4b7ff5bb663b0b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98474
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I24b11ccc7d82a9d3380fc8aa32c90ad0256485f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93831
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I0977858ea5b9d2b7ddfaa8012ef50170ee02f27d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93829
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I85c10cb957f5065d964863360ca03355c87b7980
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93821
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|