Age | Commit message (Collapse) | Author |
|
ever since
commit ddd2639a482befb4a3bf1f75a88e66c21a691b67
Date: Sat Feb 27 15:50:37 2021 +0200
drop mask from BitmapEx
Change-Id: I45fae0140067e2bfe5ce1ae2f5014ce733835ef1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118220
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
ever since
commit 2269ac65de127d33d41843ae15f6bece5bc778bc
Author: Michael Meeks <michael.meeks@collabora.com>
Date: Fri Nov 7 05:42:51 2014 +0000
icontest: remove hand-coded opengl path.
Change-Id: Ida030be0e087353e20897a9e961c9ce1134b21e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117782
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I267fbdb8946d307440cb675f6ff985bf58db5e4c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115108
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia9796cca66f405c38545a5ba3aab7c76a465a0d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115106
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1d518bef47c838d03d8526a6a8fffd36d2ee68d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114074
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
We can cast the PixelFormat enum to int for the same information
and we can use the enum to reduce ambiguity when possible.
Change-Id: I6ea648139465568cdeb12e5f5f75c7b609365bf4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113188
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
on a path to simplifying our internal bitmap stuff, aiming to
support a smaller set of image formats, but support them
in an accelerated fashion.
Change-Id: I5f8bf3cd49abf16ce460771492cdd5f358cb34df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113313
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
IRC chat:
<quikee[m]> noelgrandin: doesn't adding operator bool to Bitmap
has the same problem as Graphic and the reason why you dropped that
commit 7334034ae93b49fc93b5859a3c047a319d138282
"drop Graphic::operator bool"
<noelgrandin> quikee[m], hmmm, good point
<noelgrandin> maybe I should just drop both operator bool and
operator! in favor of IsEmpty
<quikee[m]> noelgrandin: I don't remember what the problem is I just
remembered we dropped it Graphic :) sure, dropping everything for
IsEmpty is probably the best
Change-Id: Ieae289cda64f0b8d8fdecd5ea9e6f2bb874ff4cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113163
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so we can use a more natural syntax than "!!"
Change-Id: I8152a0d3ce37115fc83d332a26725ca1d28d959a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113147
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Bit count for the image is a numeric value (sal_uInt16) but only
a handful of values make sense - namely 1,4,8,24 and 32. This
replaces the numeric value with an enum, which only accepts those
values and checks the correct values are used at compile time.
Change-Id: I0fc137c62bce3b0d021f05019a1648da628521bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112408
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I0bc9cf6d72e15ed9b47c353a3350c6ebd2e8376f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108038
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I6ffe438fa4b12d51eecb73a79c9443240e1d4695
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107949
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Id0b5f95716ba0bd14f634d927ffb7a71c0bc5767
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107505
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
This is only for the 64-bit windows platform.
I don't see the point in messing with the 32-bit platforms, they are
(a) become more and more rare
(b) unlikely to even have enough available process memory to load extremely large calc spreadsheets
The primary problem we are addressing here is bringing
Windows-64bit up to same capability as Linux-64bit when it
comes to handling very large spreadsheets,
which is caused by things like tools::Rectangle using "long",
which means that all the work done to make Libreoffice on 64-bit
Linux capable of loading large spreadsheets is useless on Windows,
where long is 32-bit.
The operator<< for tools::Rectangle needs to be inside
the tools namespace because of an interaction with the cppunit
printing template stuff that I don't understand.
SalPoint changed to use sal_Int32, since it needs to be
the same definition as the Windows POINT structure.
Change-Id: Iab6f1af88847b6c8d46995e8ceda3f82b6722ff7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104913
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
partly to flush some use of "long" out the codebase,
but also to make it obvious which units are being used
for angle values.
Change-Id: I1dc22494ca42c4677a63f685d5903f2b89886dc2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104548
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ice1055021e8568634e9a66ba89d3bb4ef4e731df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104522
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Only the grey palette with 256 colors means that pixel values map
directly to color values. Tdf#121120 has an image with 2-bit
palette where color index 1 is (255,255,255), but that means
the pixel value 1 cannot be just treated as color.
Change-Id: Ifbd953af7f291e4fb8032ea0f4c33c0514770856
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97283
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Ib1c36a35ffa6af535b5265f753e9b7a6bfb590a6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92841
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
AlphaMask doesn't need any conversion to gray, it's just enough
to make sure the alpha channel bitmap is 8bpp. And the conversion
is needed for the separate-OutputDevice-alpha hacks, where
GetBitmap() gives non-8bpp bitmap for the alpha contents, but there
all the R,G,B channels are the same, so just take red and avoid
pointless conversion.
Change-Id: Ib30fc8fa6d05067d582402ab2c0fcfb49a3742f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91772
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
In the commit below, I removed the 1-bit dithered output,
so restore it.
regression from
commit b5699cd01b6a52906880c107bac6f3802ea7353d
Date: Wed Feb 8 16:18:32 2017 +0200
convert BmpConversion to scoped enum
Note that this bug has been around since LO5.4
which means that anyone who has adjusted their
setting in
officecfg/registry/schema/org/openoffice/Office/Common.xcs
with key BMP
runs the risk of having that setting now revert to its
prior (documented) meaning.
Change-Id: Ibbda8aefbac261ff37ffab7223714f5d0343c692
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88528
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so we return a const& for the normal case, just like other methods,
which reduces copying.
This revealed that CreateDisplayBitmap in Bitmap can be const.
Change-Id: I9f9b9ff0c52d7e95eaae62af152218be8847dd63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86836
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
not sure where this is coming from, but without it, I see
warning messages about bitmaps having the wrong depth
Change-Id: Iee1a68ced73333a22b811dc31afb32df14709f18
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85946
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This should enable using move semantics where possible e.g. in standard
containers.
According to https://en.cppreference.com/w/cpp/language/move_constructor:
To make strong exception guarantee possible, user-defined move
constructors should not throw exceptions. For example, std::vector
relies on std::move_if_noexcept to choose between move and copy
when the elements need to be relocated.
Change-Id: I6e1e1cdd5cd430b139ffa2fa7031fb0bb625decb
Reviewed-on: https://gerrit.libreoffice.org/77957
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Default, Fast, BestQuality scaling flags are used for selecting
the best sclaing algorithm for a specific task, but not all
specialized sclaing algorithms have its own flag (Super,
NearestNeighbor) and are just selectable using one of the above.
This adds the missing flags so it's possible to select a specific
algorithm.
Change-Id: Ied41f27a21a4fcc799537396f9077a9c77cc1c60
Reviewed-on: https://gerrit.libreoffice.org/75759
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I52efd8d843d0e4cc7a6adefb0eb95aa50469af38
Reviewed-on: https://gerrit.libreoffice.org/73693
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Hopefully fixes problems on 32-bit linux.
Change-Id: I1fc22f1bb37c8297bd3bd6828206d1ffa9ae722d
Reviewed-on: https://gerrit.libreoffice.org/70241
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I7190a44d4857fd337fb49e689cd71ffb78b86b9d
|
|
Its comment, "if not NULL then this is actually an HBITMAP", makes me
wonder whether we lost some functionality, or broke something, or
pessimized code, when the field became unused, whenever that was...
Change-Id: I8bc95a1c5aca3ed80448c7c03ae0b1bb586bf5ae
|
|
Change-Id: I389f98d06058ba65a8c2d4df2bf7d4e5102659ad
Reviewed-on: https://gerrit.libreoffice.org/65017
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I09a0eb661b66da78d8b3809124930bc761960712
Reviewed-on: https://gerrit.libreoffice.org/64064
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: If18c80fc64e55d797953e24e40e5d5e62bd9c625
Reviewed-on: https://gerrit.libreoffice.org/63453
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
since we hold it like that in Bitmap anyway
Change-Id: I6264dfaaae6210cb008df5db8a421fc80c508f5b
Reviewed-on: https://gerrit.libreoffice.org/55458
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iefe5be4349475a4aa0138534cf6bfe87ff7df245
Reviewed-on: https://gerrit.libreoffice.org/53280
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
and add
BitmapEx::operator=(Bitmap const &)
Image::Image(Bitmap const &)
to lessen the fallout
Change-Id: Iff5fab88d167a7be739c370c9933d36c297bc61c
Reviewed-on: https://gerrit.libreoffice.org/54162
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I510d7b286df732712aa9206b0a7c7910af34c83f
Reviewed-on: https://gerrit.libreoffice.org/53206
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I84868b3115c534a8240394283cc3beedf8cb3a80
Reviewed-on: https://gerrit.libreoffice.org/53543
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If779cf4033948601997a932839eaa10a874de1b3
Reviewed-on: https://gerrit.libreoffice.org/53205
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I6e541e9ca9cf61dfa8df9638a4ba4b8bd1d3ad71
Reviewed-on: https://gerrit.libreoffice.org/53204
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Ia0910ae9166c4eb6b870ab25db761bc1703fec68
Reviewed-on: https://gerrit.libreoffice.org/53203
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I96a4072bf919bd37b30c01ab16d98779c76717ab
Reviewed-on: https://gerrit.libreoffice.org/53202
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I3d615bcce851cb0f0140e2a1542a4073727a51be
Reviewed-on: https://gerrit.libreoffice.org/53201
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I7b81d0441b5ffdc322a19ca1fea7c7ca63e9e499
Reviewed-on: https://gerrit.libreoffice.org/53151
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I2082d7e3b90172b4517ad0f4be75f85006eb5891
Reviewed-on: https://gerrit.libreoffice.org/53150
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I72a0546c11d6ef8a8a4eb467d566d639c88dc8b9
Reviewed-on: https://gerrit.libreoffice.org/53130
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I0203e98d29192ef098719c0a297b967710b8729a
Reviewed-on: https://gerrit.libreoffice.org/53097
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I62d95cc8bbf7b9349b1abc3e58bf0a202e3afec5
Reviewed-on: https://gerrit.libreoffice.org/53091
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I9dc6e81149eae3ba2284fa7fe608dd9252503dce
Reviewed-on: https://gerrit.libreoffice.org/53197
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I32b58e8d451e7303e94788a546a5b5f9a5bb4590
Reviewed-on: https://gerrit.libreoffice.org/53037
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I996c9fcb0524e14e0093142be0749f0e5836426b
Reviewed-on: https://gerrit.libreoffice.org/53071
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
it's not adding anything useful, just hold the underlying SalBitmap
instead
Change-Id: I54852707b2f8af99283b9c882a428a8a7a11c4cf
Reviewed-on: https://gerrit.libreoffice.org/52955
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|