GetOutputWidthPixel() and GetOutputHeightPixel() both return a value of
type tools::Long, representing an offset width and height in pixels.
Since aSquare and aCandidateSquare multiply these values, it seems
reasonable to use sal_uInt64 here just in case of larger displays.
Change-Id: Idacf8e7c43e884b72699ee1d521d1e0dbf4715a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194942
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Tested-by: Jenkins
this path is no longer the default for gtk3 where the SDPR renderer is
the default so there:
export DISABLE_SYSTEM_DEPENDENT_PRIMITIVE_RENDERER=1
is needed, though it is still the default for the gen backend, so that
can be used too
Change-Id: If64b7805ee4987ceab5af99decdf755280270e02
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194079
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
There is definitely a better fix for this, we should not need two
different bitmaps and masking and stuff, but this will fix the problem for now.
Mostly revert the following commits:
commit 7278030b92
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Mon Sep 15 16:26:25 2025 +0200
remove unused DrawModeFlags
commit 581c52dad2
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Wed Sep 10 15:08:04 2025 +0200
BitmapAlphaClampFilter is dead since
commit e7b460f919
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Sat Aug 30 15:23:11 2025 +0200
BitmapEx->Bitmap in canvas
Change-Id: Ic5747ce6143a8320f977111c7635bf736a9996d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193873
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
VclPixelProcessor2D::processPatternFillPrimitive2D and
impBufferDevice were independently calculating the mask rect in
different ways. So move the calculation to the callers.
This only fixed a tiny part of the problems in this bugreport,
it just helps with off-by-one at zoom levels.
Change-Id: I933f5271e31ba79794951a6b1f469fc28094d0a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192572
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
This is the same thing I did in
commit 3cbe3a0259
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Mon Jun 14 15:05:59 2021 +0200
tdf#101083 speed up SVG rendering with pattern fill
but cut and paste from the VclPixelProcessor2D to the CairoPixelProcessor2D code.
Which makes this SVG render in reasonable time when using the cairo backend.
We can probably do even better by cutting out the usage of VCL here, but this
is good enough for now.
Change-Id: I959539741eef627b25702c91cad3e5f8ee2b3176
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192394
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This is follow up to commit:
commit b9f0caad5d
Author: Khaled Hosny <khaled@aliftype.com>
Date: Tue Aug 23 04:13:28 2022 +0200
tdf#66819: Disable ligatures with character spacing
Even though editengine was applying letter spacing, when drawing with
drawinglayer, letter spacing was not propagated which caused VCL to not
disable the ligature features.
Change-Id: Ia8bf2231478720262484a757e16fe5afec3cd28e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191512
Reviewed-by: Khaled Hosny <khaled@libreoffice.org>
Tested-by: Jenkins
regression from
commit cd93f83bbc
Author: Armin Le Grand (collabora) <Armin.LeGrand@collabora.com>
Date: Thu Aug 7 21:02:41 2025 +0200
tdf#167831 avoid painting bitmap data with zero dimensions
we cannot skip these fills if the fill bitmap is too small,
we need to fill with something or the resulting picture
is very wrong
Change-Id: I194b59414db8f675df2415c3ee4fb9a0305611b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190981
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
to move the logic of constructing a new Bitmap from an existing Bitmap and an AlphaMask,
into vcl, where it can later be optimised
Change-Id: I2af1c6d1a35d968abdd07546448f7e211772e70b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190366
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
regression from
commit c2fedef548
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Wed Aug 6 20:35:05 2025 +0200
BitmapEx->Bitmap in Graphic
the problem here, is that we are now allocating a single 32-bit bitmap instead
of a 24-bit bitmap and an 8-bit bitmap.
The crashtesting file has an image of size 17000 x 17000, which hits the
size > SAL_MAX_INT32/2
check in ImplCreateDIB the svp backend.
Change-Id: Ic76eb03adeedcfbb7d60e78405641035e3eb7087
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190323
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
After commit 7caf45bc06 (BitmapEx->Bitmap
in HitTestProcessor2D, 2025-08-15), I saw a crash when hovering mouse
over a bitmap on a slide:
vcllo.dll!BitmapReadAccess::GetScanline(__int64 nY) Line 50
vcllo.dll!BitmapReadAccess::GetColor(__int64 nY, __int64 nX) Line 100
vcllo.dll!Bitmap::GetPixelColor(long nX, long nY) Line 1894
drawinglayerlo.dll!drawinglayer::processor2d::HitTestProcessor2D::checkBitmapHit(basegfx::B2DRange aRange, const Bitmap & rBitmap, const basegfx::B2DHomMatrix & rTransform) Line 174
drawinglayerlo.dll!drawinglayer::processor2d::HitTestProcessor2D::processBasePrimitive2D(const drawinglayer::primitive2d::BasePrimitive2D & rCandidate) Line 478
drawinglayerlo.dll!drawinglayer::processor2d::BaseProcessor2D::visit(const rtl::Reference<drawinglayer::primitive2d::BasePrimitive2D> & rCandidate) Line 50
drawinglayercorelo.dll!drawinglayer::primitive2d::BufferedDecompositionPrimitive2D::get2DDecomposition(drawinglayer::primitive2d::Primitive2DDecompositionVisitor & rVisitor, const drawinglayer::geometry::ViewInformation2D & rViewInformation) Line 81
drawinglayerlo.dll!drawinglayer::primitive2d::DiscreteMetricDependentPrimitive2D::get2DDecomposition(drawinglayer::primitive2d::Primitive2DDecompositionVisitor & rVisitor, const drawinglayer::geometry::ViewInformation2D & rViewInformation) Line 46
drawinglayerlo.dll!drawinglayer::processor2d::BaseProcessor2D::process(const drawinglayer::primitive2d::BasePrimitive2D & rCandidate) Line 43
drawinglayerlo.dll!drawinglayer::processor2d::HitTestProcessor2D::processBasePrimitive2D(const drawinglayer::primitive2d::BasePrimitive2D & rCandidate) Line 553
drawinglayerlo.dll!drawinglayer::processor2d::BaseProcessor2D::process(const drawinglayer::primitive2d::Primitive2DContainer & rSource) Line 67
svxcorelo.dll!sdr::overlay::OverlayObjectList::isHitLogic(const basegfx::B2DPoint & rLogicPosition, double fLogicTolerance) Line 94
svxcorelo.dll!SdrHdl::IsHdlHit(const Point & rPnt) Line 948
svxcorelo.dll!SdrHdlList::IsHdlListHit(const Point & rPnt) Line 2306
svxcorelo.dll!SdrMarkView::PickHandle(const Point & rPnt) Line 2117
svxcorelo.dll!SdrMarkView::MouseMove(const MouseEvent & rMEvt, OutputDevice * pWin) Line 1849
svxcorelo.dll!SdrObjEditView::MouseMove(const MouseEvent & rMEvt, OutputDevice * pWin) Line 2210
svxcorelo.dll!SdrCreateView::MouseMove(const MouseEvent & rMEvt, OutputDevice * pWin) Line 314
svxcorelo.dll!SdrView::MouseMove(const MouseEvent & rMEvt, OutputDevice * pWin) Line 223
sdlo.dll!sd::FuDraw::MouseMove(const MouseEvent & rMEvt) Line 260
sdlo.dll!sd::FuSelection::MouseMove(const MouseEvent & rMEvt) Line 611
sdlo.dll!sd::ViewShell::MouseMove(const MouseEvent & rMEvt, sd::Window * pWin) Line 689
sdlo.dll!sd::DrawViewShell::MouseMove(const MouseEvent & rMEvt, sd::Window * pWin) Line 405
sdlo.dll!sd::Window::MouseMove(const MouseEvent & rMEvt) Line 248
The problem was pre-existing miscalculation of the pixel indices, which
were hidden previously by BitmapEx::GetAlpha sanitizing the input.
The calculation must not round, but truncate: we are on the first pixel,
until we cross the "1/aSizePixel.Width()" boundary. Also, we must handle
1.0 separately in aRelativePoint, because that special case produces bad
result: we must either treat it as "outside" (treat aUnitRange as half-
open interval), or as "over the last pixel" (implemented here now).
Change-Id: Id39dbd889e8d6f3e063962b2a621d0c438a1f90a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189670
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
See task, there may be bitmap-filled objects in files that
have a logical size of (0, 0), despite the bitmap having
valid data. That leads to problems *inside* cairo paint,
so I have to test and avoid that.
Change-Id: I18db3b030fb5cdf77caa5afd1bf901095fa1c67b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189135
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Since 6c8b802051 which is
'StripPortions: full Primitive usage for EditEngine Paint'
all DrawText_To* methods were already using a full
conversion to Primitives which then get painted directly,
see commit comment there.
Since then no complaints/errors came up I now continue
to move EditEngine to Primitive usage. Lots of code for
the still also existing DirectPaint gets removed.
I also drive forward changes to have less parameters
for the ImpEditEngine::StripAllPortions method. It is
already cleared by the former possible rotation, this
can (and is) replaced by embedding the result to a
transform primitive doing that rotation. I changed
two of three using methods to strip always to
position (0, 0) which can also be unified to embedding
to a transformation. The third one will need some more
work here due to doing wild things in Outliner mode in
Impress (callbacks & creating Primitives in fixed
positions for which an embedding translate would be
wrong).
When being able to strip without position and rotation
the result will be usable to be buffered, so the goal
is to re-use that, transformed as needed (translate,
scale, rotate, ...) as long as the text itself does
not change.
Change-Id: I52ab548ccbb1b5b3b16c50451a314bc7f3b39d93
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188918
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
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
Did the necessary now, despite it would be better to apply
that where the geometry gets created (primitives) or painted
(older direct-apints to OutputDevice).
Instead it's in Outputevice where care is taken to apply
changes based on DrawModeFlags. Remember that this is then
done in the renderer.
This will need to be done in every renderer in the future
then. It is traditionally done in OutputDevice, completely
missing in PresentationMode and added now to CairoSDPR.
Problem is that it is not defined how to apply that, e.g.
(even in OutDev) painting text may lead to decompose and
fill the resulting polygons, so the ::*Fill flags are
applied while I think the ::*Text ones should be used.
I looked a lot at OutDev and what it does and tried to
mimic it as good as possible, but cannot give guarantees,
as mentioned in the example above.
If we assume that (as usual) the definition of what should
happen is the existing stuff when using OutDev this might
cause some further errors/regressions in HighContrast
and Black/White/Gray/Settings stuff. Luckily most of that
seems to be used in UI/Button rendering when using
OutDev, so should not lead to big problems. OTOH if
we want to use SDPRs for that in the future we would need
that anyways...
One more note: the fixes already applied may be removed
again after this is applied.
Change-Id: Ie6eb1cd4ee51c62beb950030a0a5d00d3705be61
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188527
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Daniel