regression from
commit 990b2cb056
Author: Noel Grandin <noel@peralex.com>
Date: Mon Jun 21 13:00:07 2021 +0200
simplify and improve Wildcard
Cannot pass a string_view into something expecting a char* because
then it gets the length wrong.
Change-Id: I638660a1e9a8a0d17e4d2f77500b3f01365a43d3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131396
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
On 32bit platforms tools::Long is 32bit, which is not enough
for pixel coordinates with 1m+ Calc rows+. So do not allow jumbo
sheets for such platforms.
Change-Id: I2ebd56a051470d33fca967918af3e7d2b0172dc7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130713
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
ee0e19296b make the macro unconditional,
but that means it calls both DbgUnhandledException() and
DbgGetCaughtException(), and then log it as SAL_WARN that's
a no-op. With the document from tdf#105036 it added ~13% CPU time.
Change-Id: I9360169e6e3976d40271bc5602765e56f58971d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130069
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
It's been a source of numerous problems since the beginning.
Poor separation of C++ code causing the compiler to emit some generic
code as CPU-specific, compiler optimizations moving CPU-specific
code out of #ifdef to unguarded static initialization, etc.
And it doesn't seem to even particularly improve performance,
on my Ryzen2500U for one full column (1m cells) sumArray() takes
about 1.6ms with AVX, 1.9ms with SSE2 and 4.6ms with generic code.
So SSE2 code is perhaps worth it, especially given that SSE2 is our
baseline requirement on x86_64 everywhere and x86 on Windows,
but AVX+ is nowhere near worth the trouble.
So this code removes all AVX+ code from Calc, and makes SSE2
a hardcoded option on where it's guaranteed. If we raise the baseline
to AVX, the SSE2 code may be replaced by the one removed by this
commit. Generic code is there for other platforms, if other platforms
add CPU-specific code, they should preferably follow the same rules.
This does not necessarily mean that CPU-specific code cannot
be used at all. Some externals use them, for example. It just
needs to be working, maintained, and worth the trouble.
Change-Id: I5ab919930df9d0223db68a94bf84947984d313ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129733
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
Its data only takes 16 bytes, the same as std::string_view on 64-bit
platforms, which is considered trivial. No need to use cow_wrapper
that would itself take 8 bytes, and have the performance penalty.
Also reuse the conversion to sequence from comphelper.
Change-Id: I3e3177ea759bf22d099aaa5402559196c5934ee0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129679
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...after ea771e85b2 "Resolves: tdf#146997 use
sal_Int64 instead of sal_Int32 for spinbutton values" changed the default values
of pcr::ONumericControl::setMin/MaxValue
(extensions/source/propctrlr/standardcontrol.cxx) from int to sal_Int64 limits.
With SAL_USE_VCLPLUGIN=gtk3, in Writer creating a "Form - Label" and selecting
"Control Properties" in its context menu caused
> include/tools/helpers.hxx:75:93: runtime error: 9.22337e+18 is outside the range of representable values of type 'long'
> #0 in FRound(double) at include/tools/helpers.hxx:75:93
> #1 in (anonymous namespace)::GtkInstanceSpinButton::fromGtk(double) const at vcl/unx/gtk3/gtkinst.cxx:16443:16
> #2 in (anonymous namespace)::GtkInstanceSpinButton::get_range(long&, long&) const at vcl/unx/gtk3/gtkinst.cxx:16521:15
> #3 in weld::MetricSpinButton::update_width_chars() at vcl/source/window/builder.cxx:258:24
> #4 in weld::MetricSpinButton::set_range(long, long, FieldUnit) at include/vcl/weld.hxx:1991:9
> #5 in weld::MetricSpinButton::set_min(long, FieldUnit) at include/vcl/weld.hxx:2005:9
> #6 in pcr::ONumericControl::setMinValue(com::sun::star::beans::Optional<double> const&) at extensions/source/propctrlr/standardcontrol.cxx:401:38
and similarly for pcr::ONumericControl::setMaxValue:
For one, for fVal = -9223372036854775808 (i.e., -2^63), -fVal + 0.5 (i.e.,
9223372036854775808.5) was outside the range of 64-bit tools::Long, so rewrite
the non-positive branch in a simpler way (and I have no idea why it was written
in the more complex way in the first place).
For another, for fVal = 9223372036854775807 (i.e., 2^63 - 1), fVal + 0.5 (i.e.,
9223372036854775807.5) cannot be represented as IEEE 754 double exactly and is
represented as 9223372036854775808, which was similarly outside the range of
64-bit tools::Long, so treat that limit value specially on the positive branch.
Change-Id: Ic2a553e9ce6319eac591058b1218b29dffaeab2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129638
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
In some functions author forgot that addCommaBeforeField()
can add additional two characters.
I didn't change cases where more bytes than needed are requested.
Additional change is that in debug mode there is a marker at the
end of allocated buffer - we check that after every write to
detect overflow. No need to request more space for a marker as
we always allocate "needed size * 2".
Change-Id: I28066797b0ba833e408b0a731abc01b7fd989da3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126535
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129163
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Flush() turns into a sync() on the device, which is pretty slow.
Most of the time all we actually want to do is to flush the internal
buffers from the SvStream.
So expose the FlushBuffer method and use that where possible.
And also means we don't need the mbDontFlushOnClose flag on SvStream
any more.
Change-Id: Ibe089b88b325f0fdc565200a97ce72cd26b7fcfb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128214
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The listfonts utility gets the details of all available fonts on the
system. It prints out the information, or stores it in a text file,
if a file name is passed to it as an argument.
An example invocation to store the information in a file named
fonts.txt is:
./bin/run listfonts fonts.txt
To get the correct font metrics, you actually have to get the font
metric from the system, and then set it as the current font of
OutputDevice, then get the font metric (which corrects a variety of
things like the orientation, line, height, slant, etc. - including
converting from logical coords to device coords).
The information is reported for each font family. On the top is the
family name, and then comes other details. Here is a report for an
example font:
FreeSans
Family type: swiss
Style name: Regular
Weight: normal
Italic: none
Pitch: variable
Width type: normal
Alignment: top
Charset: UCS2 (aka Unicode)
Symbol font? no
Ascent: 13
Descent: 3
Internal leading: 0
External leading: 2
Line height: 16
Slant: 0
Bullet offset: 0
Fullstop centered? yes
Orientation: 0 degrees
Quality: 18477
There is a -v (or --verbose) option that output font features.
Change-Id: Icfc4da96459bea47c4233a5509496566c04d460c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127365
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
In Change Tracking, show deleted table rows in cyan and
inserted rows in pink. In this case, don't show original
table row or cell background.
Follow-up to commit f481c2c8e7
"tdf#144057 sw track changes: hide deleted table rows".
Change-Id: Ib9cc411b62b92bc8a83dda7589f3e798f7e96f41
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126482
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
SvLockBytes is only inherited by UcbLockBytes, and that one is not
inherited by anything, so there's no diamond inheritance, so there's
no point. Probably a case of somebody not really understanding
virtual inheritance and using it "just in case".
Change-Id: I2c01f29634c4f1ff2b55d7552fc571b653878ace
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126074
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
To be used when a filtered theme color will be applied on the UI, and
not at PPTX import time.
Change-Id: Ifb56e38e59b529ef436063c407ee156d76a77f9c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126011
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Remove the temporary buffer in INetURLObject::setAbsURIRef,
and just write directly to the main buffer.
This is a behaviour change since we are "committing" bad data to the
buffer if the URL is incorrect, but since it that case we set the
whole object to be invalid, that should not matter.
Change-Id: Ic8e7d4027bcb927005edd7de4098f4f525412869
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125648
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This potentially allows to introduce other degree fractions easily,
like Degree<sal_Int64, 60000>, with automatically defined conversion
functions.
Change-Id: Id1c32d9e029943844bdc833178c1f99387ff87fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125640
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tweak INetURLObject to reduce the number of
OUString and OUStringBuffer we create,
saves 5%
And add a asView() method to OUStringConstExpr,
to make it easier to pass to OUStringBuffer::insert
Change-Id: I115ec2398cfc8df39bd1efbbd5f0d5cc9712dba7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125600
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tweak INetURLObject::parseHost so it doesn't need its own
OUStringBuffer, and can just use the callers'
Saves 5%
Change-Id: I481fabd4272bc9f172dd751a7019090b95a65e2d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125599
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Otherwise the possible copy emitted compiled with CPU-specific
instructions might be chosen as the copy to keep and would be
used by generic code. See history for the Calc Kahan code.
Change-Id: Ifc1bbd8d9720d9effe05b8ff8ee5e804363939df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124257
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Move ensureSpace code to json_writer.cxx, and merge with reallocBuffer.
The methods are private, and are only used in methods in the same .CXX,
so the code will get inlined as compiler decides anyway, but becomes
simpler.
Make extractDataAs* to consider the known size of the data, to avoid
calculating null-terminated size. To do that, the code is moved from
extractData to private extractDataImpl, which returns both pointer
and size.
Change-Id: I7c0e425b5c584089c6e866c31d4cfdb5e242d66b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123568
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
In the process, it turned out that there was unnecessary conversion
of OStringBuffer to OString and back to OStringBuffer when using
putRaw, which is avoided now.
Change-Id: I1e3ee685679df0b025bee8f4430624ee5bc9ccb3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123547
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...for LIBO_INTERNAL_ONLY, instead of having them as additional overloads. That
way, loplugin:bufferadd and loplugin:stringviewparam found many further
opportunities for simplification (all addressed here). Some notes:
* There is no longer an implicit conversion from O[U]String to O[U]StringBuffer
(as that goes via user-defined conversions through string_view now), which was
most noticeable in copy initializations like
OStringBuffer buf = someStr;
that had to be changed to direct initialization,
OStringBuffer buf(someStr);
But then again, it wasn't too many places that were affected and I think we can
live with that.
* I made the O[U]StringBuffer ctors taking string_view non-explicit, mainly to
get them in line with their counterparts taking O[U]String.
* I added an OUStringBuffer::lastIndexOf string_view overload that was missing
(relative to OUStringBuffer::indexOf).
* loplugin:stringconstant needed some addition to keep the
compilerplugins/clang/test/stringconstant.cxx checks related to
OStringBuffer::append and OStringBuffer::insert working.
* loplugin:stringviewparam no longer needs the special O[U]StringBuffer-related
code that had been introduced in 1250aecd71
"loplugin:stringviewparam extend to new.."
Change-Id: Ib1bb8c4632d99b744e742605a9fef6eae959fd72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122904
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
remove some of the naming limitations, and handle pointer parameters
better.
I only let the plugin run up till vcl/
Change-Id: Ice916e0157031ab531c47f10778f406b07966251
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122892
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
When Generic/X11 VCL backend plugin loads SVG icon,
it creates virtual device for rasterizing an SVG icon,
which in turn tries to load an SVG icon,
and thus infinite recursion happens.
Change-Id: I7559b6255e6718e64ef4a6e7c79d597375e5823a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122344
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Reading 'rectA.IsInside( rectB )' kind of suggests that the code
checks whether 'rectA is inside rectB', but it's actually the other
way around. Rename IsInside() -> Contains(), IsOver() -> Overlaps(),
which should make it clear which way the logic goes.
Change-Id: I9347450fe7dc34c96df6d636a4e3e660de1801ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122271
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Tested-by: Jenkins
581b2cf796 cleaned up some usage of the class and removed
getX()/getY(). But that means that the (probably most) common case
of treating rectangles as x,y,w,h now doesn't work, and one has
to use either left,top,right,bottom (which doesn't always mentally
fit), or the IMO weird left,top,width,height.
Change-Id: Ie9516f69af48490635346c76821be9a9eedd686c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121079
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
This part focuses on allowing it on replacing arrayfunctor
By thefault it will try AVX512F (1,17%)
If not available will use AVX (94,77%)
Use of AVX2 (82,28%) has been avoided even if the code could been more compact
Source of hardware statistics: https://store.steampowered.com/hwsurvey
Change-Id: Iae737a565379e82c5f84f3fdee6321ac74f59d40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115675
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
... instead of using confusing/ambiguous size having two interpretations.
This reverts some of the unit test changes made in commit
fa339b3adb.
Change-Id: Ic56417703e32c1d92bcee76ad8ff494824bd4a1f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120564
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Andrea Gelmini