diff options
author | Noel Grandin <noel@peralex.com> | 2020-10-28 08:30:36 +0200 |
---|---|---|
committer | Noel Grandin <noel.grandin@collabora.co.uk> | 2020-11-11 06:34:17 +0100 |
commit | 3d90997fb6f232d8008df4d166d7b97b869c200f (patch) | |
tree | d26a1756dac5b7b55fac0f4322fe25ea02e9017e /include/vcl | |
parent | 3de38e95561ab7ca114d9f3307702ba89c4e3e9a (diff) |
make tools::Long 64-bit on Windows platform
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>
Diffstat (limited to 'include/vcl')
-rw-r--r-- | include/vcl/bitmap.hxx | 2 | ||||
-rw-r--r-- | include/vcl/devicecoordinate.hxx | 3 | ||||
-rw-r--r-- | include/vcl/metaact.hxx | 2 | ||||
-rw-r--r-- | include/vcl/salgtype.hxx | 6 |
4 files changed, 7 insertions, 6 deletions
diff --git a/include/vcl/bitmap.hxx b/include/vcl/bitmap.hxx index 74d3a2e11724..b995111f16a4 100644 --- a/include/vcl/bitmap.hxx +++ b/include/vcl/bitmap.hxx @@ -466,7 +466,7 @@ public: void Vectorize( GDIMetaFile& rMtf, sal_uInt8 cReduce, - const Link<long,void>* pProgress ); + const Link<tools::Long,void>* pProgress ); /** Change various global color characteristics diff --git a/include/vcl/devicecoordinate.hxx b/include/vcl/devicecoordinate.hxx index 14e43b22c024..0d5eeb6aeb28 100644 --- a/include/vcl/devicecoordinate.hxx +++ b/include/vcl/devicecoordinate.hxx @@ -11,6 +11,7 @@ #define INCLUDED_VCL_DEVICE_COORDINATE_HXX #include <config_vcl.h> +#include <tools/long.hxx> #if VCL_FLOAT_DEVICE_PIXEL #include <basegfx/point/b2dpoint.hxx> @@ -19,7 +20,7 @@ typedef double DeviceCoordinate; #else /* !VCL_FLOAT_DEVICE_PIXEL */ #include <basegfx/point/b2ipoint.hxx> -typedef long DeviceCoordinate; +typedef tools::Long DeviceCoordinate; #endif /* ! Carpet Cushion */ diff --git a/include/vcl/metaact.hxx b/include/vcl/metaact.hxx index 52c1bf7d935d..600afe9b6790 100644 --- a/include/vcl/metaact.hxx +++ b/include/vcl/metaact.hxx @@ -503,7 +503,7 @@ private: Point maStartPt; OUString maStr; - std::unique_ptr<long[]> + std::unique_ptr<tools::Long[]> mpDXAry; sal_Int32 mnIndex; sal_Int32 mnLen; diff --git a/include/vcl/salgtype.hxx b/include/vcl/salgtype.hxx index 720c4c1d8255..d19bf776a31f 100644 --- a/include/vcl/salgtype.hxx +++ b/include/vcl/salgtype.hxx @@ -36,11 +36,11 @@ enum class DeviceFormat { constexpr ::Color SALCOLOR_NONE ( 0xFF, 0xFF, 0xFF, 0xFF ); -// must equal to class Point +// must equal to the Windows POINT type, which is why we use sal_Int32 struct SalPoint { - tools::Long mnX; - tools::Long mnY; + sal_Int32 mnX; + sal_Int32 mnY; }; typedef const SalPoint* PCONSTSALPOINT; |