V1037 Two or more case-branches perform the same actions. Check lines: 94, 99
Change-Id: I406b94c79426cebbd4813a019389d0cac0616bbf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175226
Tested-by: Jenkins
Reviewed-by: David Gilbert <freedesktop@treblig.org>
we can just take a "const &".
(found by running clang-tidy with the
performance-unnecessary-copy-initialization warning)
Change-Id: I20fd208c65303da78170b1ac06c638fdf3aa094b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176267
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
which allows us to eliminate a bunch of rounding at various layers, and
consequently maintain a lot more precision
Change-Id: I911dedd7c041c1d67396c082e5695346ea689acb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175814
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
and
cid#1633780 Initialization or destruction ordering is unspecified
cid#1633778 Initialization or destruction ordering is unspecified
cid#1633777 Initialization or destruction ordering is unspecified
cid#1633776 Initialization or destruction ordering is unspecified
Change-Id: I8ae7cbede6df2ad747fe57d0ac2800e1b6a31038
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175576
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
so we can fix a shutdown use-after-free in sot.
Change-Id: I32f83bd94627d72d7bee7ea2ebd6ab77a7f78435
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175335
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Use #pragma once instead of header guards
Change-Id: Iba43f2103628ed184933cf2611991e7aef9f0173
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173369
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
PixelSnap has to also snap control points, also
simplified some stuff in line geometry conversion
to cairo, plus more precise detection of when to
apply piyel snap
Change-Id: I41d27d8d513a62609a727dfd80f073356c901c49
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174418
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
Was not used and - if needed - should be done by embedding
the sequence of Primitives sent to it to a
ModifiedColorPrimitive2D containing the intended
BColorModifier. Keep clases as simple as possible.
Change-Id: I99de18cc971d6b396ad291ef88b59bd7599f9196
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174314
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
Added general interfaces to be able to render directly
to an RGBA target SDPR:
- processor2d::createPixelProcessor2DFromScratch creates
a target-SDPR with given pixel size and RGB or RGBA,
owning and using a cairo surface internally
- processor2d::extractBitmapExFromBaseProcessor2D extracts
rendered content to BitmapEx, including alpha
All this is currently only implemented for Ciaro, thus
the internal impls are encapsulated by USE_HEADLESS_CODE,
but already created gererally available. The return values
have to be checked to see if an evtl. shortcut is possible.
For convertToBitmapEx this means that it can do conversions
much faster than up to now for cairo when CairoSDPR is
available, else it has to to the older slower way that
also works and is the default: Create RGB content, create
Mask, RemoveBlendedStartColor (see convertToBitmapEx
implementation). This works and has the same quality,
but needs two renderings and one bitmap operation, thus
is clearly slower.
Note that these interfaces can and will be supported for
other SDPR implementations in the future, thus will make
this converter automatically faster on systems where we
will have a SDPR in the future, too.
Also note that this is the gereral converter from
a sequence of Primitives to Bitmap data, already used in
many places, inculding UNO API, thus is expected to have
some impact on conversion efficiency - if Cairo is used,
so e.g. also headless.
Change-Id: Ia638a549a04b19622892d91651317ec6727b6cd0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174266
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
Unfortunaletly we have 'virtual' OutDevs, that means their
PixelSize is bigger as they claim and they use an internal
offset. This is used to not have to create too many Windows
inside Windows (AFAIR initial reason was that Windows has
a fix number of Windows per process that can be incarnated).
The offset was/is already supported by SDPRs using
ViewInformation2D and adding ot to the ViewTransformation,
but the evtl. existing PixelSize has to be clipped against.
The fallback VclPixelProcessor2D supports that indirectly
by doing that in the OutDev commands that get called, so
it does not need to be done by that renderer.
I have now added code to support that for the
CairoPixelProcessor2D, see code and comments. It uses an
existing method of cairo to do that elegantly inside the
system-dependent code of the SDPR.
Note that the Windows SDPR D2DPixelProcessor2D will
have the same problem that will have to be solved there,
too. Since it's currently in experimental state I made
myself a note about that.
Change-Id: I68915985102bb4a63c84299f8d022ab013633510
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173998
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Use static_cast instead of dynamic_cast when it makes more sense
to do so and use auto to make the code more readable (when we
write the type 2 times).
Change-Id: I433885ab11437b1e086e0b8e255ed9dbe7e43b90
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173978
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
Added BColorModifierStack to SVG linear and radial
gradient direct support, was missing.
Change-Id: I1405ea0653180fa695b40082bf8b8520441d0620
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173871
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
This is to check all builds/tests with activated
CairoSDPR to evtl. make needed additional changes
as preparation to activate this in the future.
adapted for testTdf139000():
Use no AA offset (0.5) for applying mask.
Adapted for testDoublePixelProcessing:
The trick (hack) to create a PixelProcessor and then
attact a metafile to start recording to it does no
longer work/make sense since the VclPixelProcessor2D
is no longer the only PiyelProcessor you might get.
If it is a SDPR one (e.g. CairoSDPR) it *cannot*
record metafiles - and is not intended to do so.
Since this test was already adapted 6 years ago to
the modernized decompose of a double line to just
two lines anyways it is OK to now change to use
a VclMetafileProcessor2D now initially.
Adapted for CppunitTest_svgio:
In SvgFeBlendNode::apply execute the calls for
convertToBitmapEx without AntiAliasing to get better
edges. Input data is SVGToken::FeFlood, so a
rectangular area, so no AA needed.
Taking this back: The reason must be in the renderer,
nothing else changed. Debugged in detail through
both, problem is that VclPixelProcessor2D ends up in
CairoCommon::drawPolyPolygon and draws the polygon
AntiAliased, but just the fill and thus *not* with
the AA-offset of 0.5, that is only done for fill.
I have to re-consider the AA offset decision for filled
polygons. Checked CairoCommon again, indeed AA offset
is ony done for lines, not for fill - that corresponds
with my thoghts from the weekend. Somehow this must
have come in with copy/paste (?). Same is already
in D2DPixelProcessor2D, have to remove there, too.
Adapted for CppunitTest_sd_png_export_tests:
This was a hard one, debugged all the components used
for ConvertToBitmap/MaskCreation. Cumulated to be
some diff in processTransparencePrimitive2D, but
found no error after checking all tranmsformations.
The orig errof ro the failing test (tdf#158743)
seemed to give a hint, but ObjectTransformation
was just handled well. At the end the diff was
that VclProcessor2D uses the same processor, while
CairoPixelProcessor2D creates local instances
(what is cheap). Thus the content rendering for
TransparencePrimitive2D was *not* using the set
BColorModifierStack. Added as needed to be able
to transfer that to the content rendering
instance.
Adapted for CppunitTest_sd_png_export_tests:
Gerrit says PNGExportTests.cxx:1041 asserts,
but I cannot reproduce. Maybe at the build
system a slightly different font is used.
My only idea is to add the mentioned point
at (12,120) to the rectangles, obviously the
bottom one.
Next one is (13,82), again bottom one,
adapting.
Adapted for CppunitTest_sw_ooxmlexport16:
The test 'testTdf136841' uses a WMF that contains
XOR paint parts. This showed that that part in
CairoSDPR did not work yet as needed. Adapted
that, also the test slightly due to the color
result slightly changed with CairoSDPR.
One last change before activating in master: Add
DISABLE_SYSTEM_DEPENDENT_PRIMITIVE_RENDERER in
case it urgently needs to be switched off or to
be able to simply test if something happening is
related to CairoSDPR
Change-Id: Idb8237a05d7594efe20edfa1707ca0002185645a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173330
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
EMF has two ways to indicate that text should be treated as RTL:
- The ExtTextOut ETO_RTLREADING flag
- The SetTextAlign TA_RTLREADING flag
Previously, only the former was implemented. This change implements the
latter.
Change-Id: If1023b4a0a3b6eb2ce47d2b764edbfd1a5c0dd5a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173579
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
This reverts commit c30c1d12f2.
it even broke the original sample file reported in tdf#153008
See https://bug-attachments.documentfoundation.org/attachment.cgi?id=196248
The original issue was reported in tdf#95165 but it doesn't work
in all cases, making it much worse in some cases where images
become very stretched
Reverting for now, specially towards libreoffice-24-8 and
libreoffice-24-8-1
Change-Id: Ib94d2784d701d37853ce9b17135b36f26a5c084b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172913
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
- Add new text Glow effect properties for shapes
- Using TextGlowPrimitive for rendering uniform text glow in shapes
- Add/allow new UI Glow Effect for texts in shapes on sidebar
(Only for Impress/Draw and Calc)
- Import/Export ooxml files with Glow effect on texts in shapes
(Only PPTX/XLSX)
- Import/Export odf files with Glow effect on texts in shapes
- Add unit test for glow text attributes in ODF
- Add uni tests for OOXML import/export
Note: Also this patch effects on
tdf#144061 - Effects: Allow GLOW to apply to Text (as we have for shapes)
Change-Id: I16586c01654f197f532129e4e06aa2ef9f214395
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172216
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
VclPixelProcessor2D used PRIMITIVE2D_ID_WRONGSPELLPRIMITIVE2D
to render WrongSpellPrimitive2D using processWrongSpellPrimitive2D
and there renderWrongSpellPrimitive2D. That again used
DrawWaveLine at OutputDevice.
This again does some very special things, e.g. it uses the set
Font at the OutputDevice which hopefully is the one the
redlining refers to (info from that has to be added to the
WrongSpellPrimitive2D if needed, in this case the
LogicalFontInstance's GetWavelineUnderlineSize result). It
seems to rely on the Text being redlined being 'painted'
directly before this.
It also renders the WaveLine to a BitmapEx and does pixel-
based operations on it (probably to 'clip' the WaveLine instead
of adding needed partial curve geometry), and adds that
BitmapData to a cache.
It also mentions it 'make sure the waveline does not exceed the
descent to avoid paint problems', probably because when not
handling it as Primitive from a PrimitiveProcessor the
invalidation Range will not fit (it still uses the getB2DRange
of the WrongSpellPrimitive2D to do that part indirectly), so
these regions will probably not always have fit.
Nothing of this is needed, after I made the
WrongSpellPrimitive2D to use view-independent (aka pixel-
oriented scaling, fixed size) to behave like the current paint
the VclPixelProcessor2D can just use the decompose and render
the view-dependent and buffered visualization of the WaveLine.
NOTE: It is not possible to completely get rid of
OutputDevice::DrawWaveLine since it is used in some cases in
Writer directly, also in ImpEditEngine::Paint when the
EditEngine is painting directly (very rare now).
NOTE: Also impCreateTextPortionPrimitive did swap start/end
in preparationm to create a WrongSpellPrimitive2D (look for
tdf#151968), this will no longer be needed.
Change-Id: I31aec8ea9c2e3c574ad471082612a10d95810f3b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172331
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
given the use of rDXArray after move
.
Change-Id: I27ed26228bb4a43b6dcb6edb4586e0727389dcbb
Change-Id: I66e0a6dd1837e598b620692b405bb32f79470e44
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172116
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
Experimented with painting 'problematic' bitmaps
e.g. RGBA 1xN or Nx1 pixels -> Cairo paints out of
bounds (?), so had to clip that. For more info,
see added code comments.
Change-Id: I4dcd488e5e0c692e236136a216ad7b460d681233
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172112
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
