The change allowed to simplify many places where previously this API was
used, to avoid inefficient calculations (e.g., moving rectangle keeping
its size, and then immediately changing the size).
Change-Id: Ica2dc594d91cae83e2c2740c1f4fb23f44998916
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120461
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
If a LogicToLogic uses fixed units, we can use o3tl::convert
instead. We can also do the same for all other cases where
LogicToLogic is used, but that needs additional investigation to
determine if it is safe to do so.
Note:
MapUnit::Pixel is converted to o3tl::Length::pt because it assumed
72 PPI for a logical pixel, which corresponds with the conversion
rate of a point (72 PPI).
Today, 96 PPI is standard, which is also used for o3tl::Length:px.
Change-Id: I29126df38bfcfda74b5d83d4cb880a378aecd18b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120230
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
based on OInterfaceContainerHelper2 which is considerably
faster than the original OInterfaceContainerHelper
Change-Id: I9c8b6d0e5382018824bf7188a26343703abf2d51
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120161
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
since it is just a wrapper over SvtCJKOptions and SvtCTLOptions.
Later I will replace those two with the equivalent officecfg calls
Change-Id: I61c5667a05f75d42643175f2c28c29d7a590b15c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119516
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
... in WhichRangesContainer and SfxItemSet ctors. Now it's not needed
to explicitly use 'value' in WhichRangesContainer's ctor, or create an
instance for use in SfxItemSet ctor (svl::Items is already defined as
a template value of corresponding type).
Instead of
WhichRangesContainer Foo(svl::Items<1, 2>::value);
SfxItemSet Bar(rItemPool, svl::Items<1, 2>{});
now use:
WhichRangesContainer Foo(svl::Items<1, 2>);
SfxItemSet Bar(rItemPool, svl::Items<1, 2>);
Change-Id: I4681d952b6442732025e5a26768098878907a238
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119157
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
SfxItemSet shows up in perf profiles frequently,
and the hottest part is the malloc of the two arrays we need.
But most of the time, one of those arrays is a compile-time
constant.
So this change introduces
(*) WhichRangesContainer, which manages whether the SfxItemSet
owns the array it points at or not.
(*) a static const member in svl::Items (idea from mkaganski)
to store the data.
Change-Id: Icb8cdbc4d54fd76739565c575e16a744515e5355
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118703
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Attaching a data series to the secondary axis didn't enable
the secondary axis at the right side of the chart using the
sidebar (unlike in data series local menu -> Format Data
Series... -> Options).
Test: Click on the chart, select one of the data series, and
enable Data Series -> Align Series to Axis -> Secondary Y Axis.
Change-Id: I2cb99458af724471d4d04cac8c2c9013f41634fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117048
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
Chart Type dialog was empty, when the chart type of the chart
was unsupported.
Regression from commit: 4ff983b930
(Related: tdf#142049 restore some elements default visibility
in the ui)
Change-Id: I057e6b9218edee398af8311c46b922ca76a9bcb5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117173
Tested-by: Jenkins
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
This allows to make sure we actually use sorted which ranges,
and then it's safe to call SfxItemSet::MergeRange when needed.
Also this change relaxes the previous requirement that ranges
must be separated by at least one; this allows to have adjacent
ranges, like in
RES_FRMATR_BEGIN, RES_FRMATR_END-1,
RES_GRFATR_BEGIN, RES_GRFATR_END-1,
where RES_FRMATR_END is equal to RES_GRFATR_BEGIN. Allowing this
makes possible to (1) self-document the ranges, so it's clear
which ranges are included; and (2) be safe in case when these
constants would change, so that the one merged range would not
unexpectedly contain everything inserted between RES_FRMATR_END
and RES_GRFATR_BEGIN.
Change-Id: Iaad0f099b85059b3aa318a347aa7fbd3f6d455c7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116909
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
A new function was defined, XdataInterpreter::getChartTypeSpecificData.
Being 100% chart-type-agnostic when retrieving chart data is impossible;
candlestick charts can have different numbers of sequences per series,
and this information is not present in any other chart type.
Change-Id: I0f54b09202c42667331b083d54d90e4ceee81083
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113075
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
as part of a longer-term goal of doing our
widget rendering only inside a top-level render-
context.
I moved all of the OutputDevice-related code that existed in vcl::Window
into a new subclass of OutputDevice called WindowOutputDevice.
Notes for further work
(*) not sure why we are getting an 1x1 surface in
SvpSalGraphics::releaseCairoContext, but to fix it I clamp
the size there
(*) might have to dump VCLXDevice, and move it's code down into VCLXWindow and VCLXVirtualDevice
(*) can we remove use of VCLXDevice in other places, in favour of just talking to the VCL code?
Change-Id: I105946377f5322677d6f7d0c1c23847178a720b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113204
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Optimise LocaleDataWrapper for reads by initialising the
data we in the constructor, so we don't need any kind of
locking
Reduces load time from 34s to 28s.
Change-Id: I4bd3bddb30b70ba015fe5b1372534f9507762b74
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114960
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
look for places we are dynamic_cast'ing after static_cast'ing,
which means the dynamic_cast is a waste of time.
Change-Id: Ife11bb675020738040646230bbd038278d84f7f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111631
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Mike Kaganski