so we get bounds checking in debug mode
Note that I cannot just pass around the std::vectors
involved because there is a place in editeng which
calls with a subset of a vector.
Change-Id: I5088a139593c27bf9cbe5d843ab4b0048ac6d508
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124330
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
to match the other implementations that return the OutputDevice*
I tried enabling SpriteCanvas.OGL in
officecfg/registry/data/org/openoffice/Office/Canvas.xcu
with
<node oor:name="com.sun.star.rendering.SpriteCanvas" oor:op="replace">
<prop oor:name="PreferredImplementations" oor:type="oor:string-list">
<value oor:separator=",">com.sun.star.comp.rendering.SpriteCanvas.DX9,
- com.sun.star.comp.rendering.SpriteCanvas.Cairo,
+ com.sun.star.comp.rendering.SpriteCanvas.OGL,
com.sun.star.comp.rendering.SpriteCanvas.VCL
but it crashes before it gets very far and before it gets to this
method. I tried in 7.1 and 7.0 but the same result so I can't tell if
this fix is needed, but they surely should be the same as the others.
Change-Id: I4f3715568eb0ec3a3bc57f6e6bdf158ff530ca5c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116061
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
since we've got all the information from the beginning.
static_cast were needed to avoid this kind of error:
/home/julien/lo/libreoffice/canvas/source/opengl/ogl_spritedevicehelper.cxx:305:36: error: non-constant-expression cannot be narrowed from type 'sal_uInt32' (aka 'unsigned int') to 'double' in initializer list [-Wc++11-narrowing]
mpTextureCache->getCacheMissCount(), mpTextureCache->getCacheHitCount() }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/julien/lo/libreoffice/canvas/source/opengl/ogl_spritedevicehelper.cxx:305:36: note: insert an explicit cast to silence this issue
mpTextureCache->getCacheMissCount(), mpTextureCache->getCacheHitCount() }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
static_cast<double>( )
Change-Id: If2705251cc4a246c2b8cb0bf873d413b3c572880
Change-Id: Ie1ce45cb6518fe97442ec5f3f05d34bae586b417
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115585
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
The VCL OpenGL backend code has been removed, so the settings
for it no longer make sense.
But there's still the code for detecting if OpenGL is broken,
and that one makes sense to keep. It turns out other OpenGL code
(such as slideshows) doesn't even use that, so turn this into
a new DisableOpenGL option, make OpenGL-related failsafe code
set and use that, and OpenGL code should use
OpenGLHelper::supportsOpenGL() to make sure OpenGL use is not blocked.
Change-Id: Iec83f204e89bfb0b6eea13be77da8f0f4727a074
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107398
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.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>
It had been documented as "the macro OSL_THIS_FUNC is intended to be an office
internal macro for now", so take the liberty of removing it, even if technically
that can be considered an incompatible API change.
Change-Id: I7580a932e1da54845934378a650e894f3f3a9062
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101406
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...as discussed as an open TODO in the commit message of
fe6cce01c8 "Fix loplugin:simplifypointertobool for
libstdc++ std::shared_ptr". The necessary changes across the code base have
been done fully automatically with the rewriting plugin on Linux. (All those
changes apparently involve uses of macro arguments wrapped in parentheses in the
macro body, but always in conditionally-converted-to-bool contexts. In other
contexts, such automatic rewriting would add the "bool" to the macro body, which
would be wrong in general, but we apparently get away with that sloppy coding
for now.)
The parenExprs_ stack that fe6cce01c8 had
introduced to treat such (then-undetected, it had turned out) parenthesized
cases now turns out to not be needed after all.
Change-Id: I2021f61c2e2805be7e18b38edf8744d186cac3cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95010
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Turns out we can save about 500Mb of preprocessor input if we use
rtl_math_approxEqual from rtl/math.h instead of its C++ wrapper
rtl::math::approxEqual from rtl/math.hxx
and manage the fallout accordingly.
Before:
bin/includebloat.awk | head
sum total bytes included (excluding system headers): 19017296671
After:
$ bin/includebloat.awk | head
sum total bytes included (excluding system headers): 18535432672
Change-Id: I1691171f3a309405a7099882ad9989d147f59118
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92508
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ie1f6fe98f4e8bc792f5eae1ccdd697c997707004
Reviewed-on: https://gerrit.libreoffice.org/81930
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Except directx/
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I4504e087edfd837a3a91df49e296bbf40778b030
Reviewed-on: https://gerrit.libreoffice.org/81586
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
It was passed in as aArg[1] ever since d551190e83
"INTEGRATION: CWS canvas05", but I can't find any current use of that specific
argument in canvas/source/ (assuming that all the factories are implemented
there), nor can I find any trace in the git history of it ever havig been used.
That means that Window::GetSystemDataAny is unused now and can be removed.
Change-Id: I16efe548afb5cc3e0606cffea135f7e6674d5def
Reviewed-on: https://gerrit.libreoffice.org/80295
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This reverts commit 9865440d21.
This is not ready to land yet, seems like the latest update
of the logic reveals a bunch more places I need to fix before it can land.
verify that parameters use the exact same typedef-names (if any)
in definition and declaration
Change-Id: I55d2817f599b0253904dce2d35a1a93967e15a77
Reviewed-on: https://gerrit.libreoffice.org/68439
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: I93d516146ba44d83f84cb245e712ef6d14634a18
Reviewed-on: https://gerrit.libreoffice.org/68035
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
look for any kind of types, not just POD types, helps to find
smart pointer fields that are only assigned nullptr
Change-Id: I2d887e98db012f03b646e1023985bcc196285abc
Reviewed-on: https://gerrit.libreoffice.org/62382
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
