Since BitmapEx was unified into a single premultiplied 32-bit BGRA
Bitmap, converting such a bitmap runs a per-pixel loop that builds a
BitmapColor and dispatches through the `GetPixelFromData` /
`SetPixelOnData`, (un)premultiplying one channel at a time.
Add a fast scanline path for the common case, a premultiplied 32-bit
truecolor bitmap (ABGR/ARGB/BGRA/RGBA). It resolves each channel's
byte offset once and then moves the scanline bytes directly, using the
premultiply / unpremultiply lookup tables.
Signed-off-by: Karthik <karthik.godha@collabora.com>
Change-Id: Ie8ee47055bdffca9e06d48955fdc0b61b34e08ac
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/6752
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 54c68922eaa2d2c4e20e10091ad4911e8d32aed2)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208641
Tested-by: Jenkins
Index retrieved corresponded to blue value, that's why:
-the right circle of the first line
-the two circles from left of the second line
-the second circle of the last line
were modified.
Change-Id: I57a5334ca11f5b987d4125c88810991f83d44d42
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208817
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
... for 32-bit-with-alpha sources"
The commit broke (e.g. toolbar and menu) icons for at least
the gtk3 and qt6 vcl plugins when scaling is enabled
(s. tdf#172651).
The commit message suggests that it is primarily relevant
for Collabora Online, which doesn't use this repo anymore,
so no negative consequences of reverting it again are known.
(When testing, broken icons were sometimes still shown
with the revert in place unless starting with a fresh
user profile, probably due to icons being cached in the
user profile.)
This reverts commit 7b5ddd9311.
Change-Id: Iad735af3f41229a2263a8ce3de1c2c168ce9cecb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207560
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Convert(BmpConversion::N24Bit) returned true without touching the
bitmap when the source bit count was already >= 24, so a
32-bit-with-alpha bitmap kept its alpha channel. Callers that rely on
Convert(N24Bit) to strip alpha (e.g. the PDF/A transparency-removal
path in vcl/source/outdev/transparent.cxx) then handed an alpha
bitmap to MetaBmpScaleAction, tripping its
!HasAlpha() assertion in dbgutil builds.
Triggered in CPLinux-LOKit builds (--enable-cairo-rgba, --disable-poppler)
where pdfium-rendered PDF imports produce N32BitTcRgba bitmaps; on
PDF/A-1 re-export the transparency-removal path then crashes in
testTdf136805.
Force re-encode via ImplConvertUp(N24_BPP) when HasAlpha() is set so
the alpha channel is actually dropped.
Signed-off-by: Andras Timar <andras.timar@collabora.com>
Change-Id: I7320c5f5a873b23d4413e3183cd6ff45d9e26e08
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/1233
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit cba855cd11cda78531d486279330a73133ac7151)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207026
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
shows up when running CppunitTest_sc_shapetest
probably from the recent changes here, when calling tryToGetCairoSurface.
Rather than doing explicit cleanup, lets follow the same path used in
include/vcl/cairo.hxx
and pass around a shared_ptr that makes cleanup automatic.
Change-Id: I1bec6f579af182b259cb0edbd86192627e5c61ea
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/1858
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 70966239f816d81cb9dcb208e7c02e08339da28c)
(cherry picked from commit ee2349dba8aa282e30ae65cbf5ffbb27b707e0ec)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205990
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
In RGB case we only multiplied the first component instead of all.
This introduces mulAndAdd function to multiply each component with
the constant and adds to the array for each component. This should
fix the issue. The add() function that takes a constant was
removed.
Change-Id: I7e2620f643b49498a69437e4b572f9417f1ef6af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199919
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit b90d690da8086ec91b279ec6987a231b0775d24e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205381
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Replace memcpy() with std::copy_n() in Vectorizer.cxx, edit.cxx,
field2.cxx and imivctl2.cxx to improve type safety by eliminating
manual sizeof() calculations.
Change-Id: I8de107beb8ee4a4c5716a9b3c3540045027479c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204361
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Replace various `ImplGetSVData()->mpDefInst` by
using the existing GetSalInstance function that
returns exactly that.
Change-Id: Idef8bbdf67888dbfae1f3796428a41ccc8606d27
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200574
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Found after running bin/find-unneeded-includes --headersfwd include/vcl/[A-Z]*
This shaves off about 100M input, not bad for such a small amount
of files checked
This time --headersfwd skips files that contain #if defs,
in hope of not breaking builds that are not checked by CI
(...except for include/vcl/BitmapTools.hxx - this was cleaned accidentally,
due to a bug in the bin/find-unneeded-includes script that is fixed
by the previous commit 930ff2b830
- but let's keep this anyway, it seems fine)
Change-Id: Ia8e49d94f6adb3cdbedbc40ffa56dbf846c9b6e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196235
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
Tested-by: Jenkins
nV5RedMask, nV5GreenMask and nV5BlueMask are valid only
when used with 16-bpp or 32-bpp bitmap and the bitmap is
not compressed.
Change-Id: Ic6ca1364a12f9bc11d789e317428cd9c3e144873
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195209
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
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
BitmapScopedReadAccess may be scoped to the `if`, and then it doesn't
need explicit reset.
The inner `if` can be deduplicated, which IMO improves clarity.
Change-Id: I002d3353bc12ab42095122c65c85a2b839d543fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193660
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
regression from
commit e2b2eec732
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Sat Aug 2 11:07:19 2025 +0200
BitmapEx->Bitmap in AddonsOptions
But not really, because it just exposed that our code
in BitmapScaleConvolutionFilter did not handle alpha images properly
Change-Id: I3de9b293a92a499475f034d33bdeecd2d62891cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191953
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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>
regression from
commit 8126025906
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Sat Aug 9 19:29:08 2025 +0200
BitmapEx->Bitmap in various icons
The old BitmapEx::Replace methods had the odd behaviour that
they left the alpha layer alone, so we need to replicate that
in Bitmap::Replace
Change-Id: Ic304178fb9a45750a887bee2493546bc497eeb06
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190649
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
and
cid#1665282 Variable copied when it could be moved
cid#1665279 Variable copied when it could be moved
cid#1665278 Variable copied when it could be moved
cid#1665276 Variable copied when it could be moved
cid#1665275 Variable copied when it could be moved
cid#1665257 Variable copied when it could be moved
Change-Id: I222860c6385693610b95f4d674d4d0da59e75a5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190635
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Andrea Gelmini