| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: Idd21e966cf2c9b246c7484ba6c118c872a3dbac3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131568
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
The backend test unittest already needs some special handling (such
as not smooth-scaling in Skia backend when in HiDPI mode), but
graphics test were failing because the name of the unit test was
used for detecting whether to do special handling.
Change-Id: Ieb23915f1eeafc13c921de06475cb761dc4c485f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129292
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I1e572bd03387e1708fe75b90c2bce220b41c29e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128409
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
The docs say that Skia handles this itself, and with Vulkan excessive
flushing may show up in profiling in some cases, as it's apparently
a non-trivial operation in GPU mode. Remove even the two workarounds,
I cannot reproduce the problems anymore, so let's assume it's been
fixed in Skia.
But still keep the flushing after a certain number of operations,
as too many pending operations still may overload Skia (or Vulkan?),
besides tdf#136369 I can also reproduce it while loading bsc#1183308
which does a large number of tiny VirtualDevice's and does GetBitmap()
on them.
Also change the counter to be global, as we use just one Skia drawing
context.
Change-Id: I48b96c2a59f8e1eeef3da154dbe373a37857c4be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128293
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
so we don't need to fallback to gdi in skia for those
we build it incrementally as GetFontFromFontFace fails
in the system font set
Change-Id: I2ac6d151657b9b720eed46dd7bcee0e9682e462a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127877
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
This reverts commit 7e5af164b7d293dd410710bed411e1ca64bbecf7.
Reason for revert: Not the best/effective way to clear out the stuff remaining to be done, would need additional stuff
Change-Id: Ia6ab90384da29a5e34eff0ab8881bad2ab49c58c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126601
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Previously the caching was based on SkImage's uniqueID(), which
detects whether it's the same image. For caching to work based on
this it is required that the underlying image does not change,
which generally means using the same Bitmap(Ex) for repeated drawing.
But e.g. in tdf#146096 canvas (AFAICT) tries to cache bitmaps
by copying them around, which generates so many bitmaps that they all
do not fit in the cache (helped by the fact that the edit window
still animates them too, and bitmap caching in canvas being broken).
It feels kinda lame and unnecessary to checksum pixels of many bitmaps
to be drawn just to find out whether their drawing can be sped up,
and it really should be fixed higher up wherever it's broken, but
I've already failed several times trying to fix this in canvas,
so let's just roll with this.
This is done only for raster-based images, because GPU-backed drawing
is fast enough to deal even with expensive drawing (and fetching
GPU-backend pixels would be expensive).
On my machine this changes showing the slide from not being able
to quite keep up to about 20% CPU usage.
Change-Id: I25a362a02dc61e99b391cb305e2fdcd2feb67879
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126613
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I85e81b730dcb0fdc7728d5a956974ef09a73de87
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126585
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Unfortunately the add/usage of HasFastDrawTransformedBitmap did disable the
system-dependent implementations/fast-path for DrawTransformBitmapExDirect
and it's implemenations, except for Skia.
This means that the current backends for Windows/Mac/Cairo/headless/Qt5
have to do expensive pixel operations when a Bitmap is 'really' transformed
(rotate/shear) since some time.
The nine implementations using ::hasFastDrawTransformedBitmap (grep for it)
all return false, except the Skia one.
Since HasFastDrawTransformedBitmap() uses that and itself is used in the very
central mehod OutputDevice::DrawTransformedBitmapEx(...) to decide if that
fast-path shall/can be used at all, it was *no longer used* - except for
Skia - what makes Skia definitely performing better with transformed Bitmaps,
or the other way around - the others worse.
HasFastDrawTransformedBitmap() is used in only two places, the second is in the
canvas helper to decide if to try to use that fast-path for presentation
rendering.
A method at OutputDevice to see if that fast-path is implemented is therefore
currently needed, but for the canvas helper only. Since this will/should be
converted to primitive usage (hopefully) anyways, nine impementations calling
these virtual functions often and the danger to produce a mismatch/
error beween implementations of hasFastDrawTransformedBitmap and
drawTransformedBitmap (as happened here, but can also happen when someone
adds or removes an implementation) I looked for a way to solve that differenly
and more safe.
Since SalGraphics::DrawTransformedBitmap anyways returns a bool to signal it's
success I take this as base to implement a buffered test directly at
SalGraphics, also directly set a local flag to detect that functionality if
DrawTransformedBitmap is used anyways before the test is/would be needed.
Combined wih that small test to check only if this was not yet used and thus
tested by DrawTransformedBitmap anyways I can offer a reliable non-virtual
method at OutputDevice called ImplementsFastDrawTransformedBitmap() that will
be used at the single necessary location - in the canvas helper.
Since that small test direcly uses one of the nine implementations of
hasFastDrawTransformedBitmap it is fundamenally more reliable and probably
the copy bitmap/writeBack never really used (I tested that it works) due
to an earlier use of DrawTransformedBitmap did the check potentially already.
I also took a look at the cairo version (since I had this one running here)
and ensured that the buffering of the system-dependent form of the Bitmap
as cairo surface still works. Regarding the newly introduced fAlpha
parameter I want to add some remarks:
- It should be called fOpacity to make clear that it describes opacity,
defining that if 1.0 == fAlpha means *no* transparency. That word is
used in other graphic systems and makes more clear what function it has.
It is the opposite of transparency, but works the same.
- Currently all implementations of ::drawTransformedBitmap - except Skia
where it was implemented - do not use it, but return false. It will in most
cases not be too complicated to add/implement it, e.g. for cairo anyways a
transparency surface will/is created, fAlpha can just be merged in, and the
criteria for buffering that may be extended to remember for which value
(if at all) of fAlpha that was prepared. I strongly recommend implementing
these for our main graphic backends.
- The primitive renderer uses another more general way to add an extra alpha
channel to paint when needed - it draws the content (any content) that needs
to be transparent to a buffer and then that buffer using the intended
transparency. This is discussable since may be more expensive, but more
general and keeps the interface less complex. We can see here that adding
that complexity to the existing interface at OutputDevice makes the
implementations more complex what might be the reason his was only
implemented for one of nine backends. When adding something like this and
extending the complexity I would prefer that at the same time it gets
also *implemented* in all or most or at least most used cases. I want to
make clear that from my POV in those cases choosing possible runtime speed
over complexity is not always preferable.
Change-Id: I5bab59f59fca878a7b11a20094e49e8b50196063
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126480
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
The code already tries to hide the cost of the high-quality bicubic
scaling by caching, but there are still cases where there's too
much scaling done. Since this is only drawing to screen, use
only bilinear+mipmap scaling in raster mode, which should be good
enough (it's what the "super" scaling VCL algorithm for
BmpScaleFlag::Default does as well).
Change-Id: I75c86932e097411422dc1ef5e0534059dbf11ff8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126326
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
GCC warns that 'enum class XorMode { None }' shadows 'constexpr int
None = 0' for a workaround for X11 headers, even though there's
no case for confusion here. So instead of a workaround for X11
headers work this around by placing the enum first, and then GCC
does not complain.
Change-Id: I3e7cfaced957d47dee8cc4f10ee74e8dd97a5cc5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126083
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Up until now this has been implemented like in almost all other VCL
backends by manually xor-ing pixel values. But that required fetching
pixel values from the GPU in Vulkan mode, which is relatively slow.
Since some time Skia now has supported writing custom blending modes
using the SkBlender class, so it's now possible to drop the hack
and support xor drawing directly using a blender that does
the operation. This should be both faster and simpler.
Change-Id: Id751d0ed4034852ce68697ecf56cc6dfac95307f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126051
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
I thought it was a driver problem, but now I'm actually not sure,
as I cannot reproduce it anymore and I don't know if it was a driver
update or Skia update. Either way, this works now.
Also switch to kExclusion, because the end result is the same,
but this formula is simpler (to understand primarily, the performance
is going to be probably the same).
Change-Id: I6ced098ca4a3361cf98d3f9b32968c128eb9f299
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126050
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
All tests still pass, so the end result should be the same, but
this way it's done in one call.
Change-Id: If5da34837a45ad600ae30568e4ba7651ac5838bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125644
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
I'll want some common extra functionality there later.
Change-Id: I249f9ca4662fc8e8d52c58b1bd33293f363464d8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125643
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I16d32d51266fc32e8ee37f9e1deed4c9577764b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125316
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
The scenario is that something scales a bitmap and then asks for it
to be drawn (possibly drawn scaled again). One example is
OutputDevice::DrawBitmap() subsampling the bitmap that according
to c0ce7ca4884f7f6d1 is supposed to improve quality with headless(?)
backend, but with Skia it's pointless and it breaks things like
caching during repeated drawing, because then GetSkImage() will need
to generate a new SkImage each time.
Since Skia backend uses delayed scaling, these cases can be sorted
out by checking the stored SkImage and using it if suitable, as
the original image is as good as the rescaled one, but often
it's better - it may be cached, sometimes the scaling operations
cancel each other out (often the case in HiDPI mode).
Change-Id: I0af32f7abdf057a3bdda75247d2dc374eaf1bc4b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125311
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
They are just a set of small functions, and I sometimes need
to debug optimized builds too.
Change-Id: I6350476e8c7fef85460a88b9e3d56d02213764ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125310
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I09a1921e203e1088577abf75350c8b41e4c78381
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125265
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Since the image will be actually eventually drawn twice as big,
cache an image that is twice as big.
Change-Id: Iea0340cd92c102e453330723c797659c742feb63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125263
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
The basic idea is the same as the 'aqua' backend, simply set up
a scaling matrix for all drawing. That will take care of the basic
drawing everything twice as large, which is twice the resolution.
And then blit this data to the window, which expects data this way.
Converting back from backing surface needs explicit coordinate
conversions, and when converting to a bitmap the bitmap needs
to be scaled down in order to appear normally sized. Fortunately
I've already implemented delayed scaling, which means that if
the bitmap is drawn later again without any modifications, no
data would be lost (to be done in a follow-up commit).
Unittests occassionally need special handling, as such scaling
down to bitmap not being smoothed, because they expect exact
color values.
Change-Id: Ieadf2c3693f7c9676c31c7394d46299addf7880c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125060
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
It seems that manually writing a shader that does the same
as SkBlendMode::kDifference works fine even though the blend mode
crashes e.g. on Windows/AMD. So get rid of the memory<->GPU
conversions and use the shader as a workaround.
Change-Id: I971deeeb98f40e5ffa90f6a8dd7b0b21ec491c1a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125101
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
The size of the alpha image does not really depend in mPixelsSize,
it's created on demand and it's just necessary to check if it
has the right size.
Change-Id: Ic16c7c2b202be31c22b21b0c5ee720bda955bbbd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125059
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Ib78c661ec82456386d79680f106b6d14b66f450f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125058
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I2f01a8e67c52ece9b434777203aa9fbc9ac8be02
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122613
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
The convention is that we need to add sal/config.h to the start of
files.
This patch is created in preparation of a patch I have queued to test
and move PhysicalFontFace to vcl::font namespace.
Change-Id: I15dd24d7f01e077d407ac192a0413d796517eb72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122228
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This patch is created in preparation of a patch I have queued to test
and move PhysicalFontFace to vcl::font namespace.
Change-Id: I805a8bd1fa881fc4bc6d2f26f1051b9247587701
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122226
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I31ee84be7ebee7f1644d7fd43bbc951abd2842d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121328
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Previously the code called window context's getBackbufferSurface()
once, and the repeatedly used it for drawing and then did
swapBuffers(). This worked until version chrome/m91, now Skia
requires that a screen drawing pass is calling getBackbufferSurface(),
drawing to it and calling swapBuffers(). Since we do not always
draw full window content and instead keep previous content, use
a separate offscreen surface for that and for actual screen drawing
just blit that to the screen surface.
Change-Id: I36a5b3bb23a085936f4473a0e00d8e04c6b40dab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120966
Tested-by: Luboš Luňák <l.lunak@collabora.com>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I29b9f54d24aece32949ac3ba916f1d6588cfd85f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120910
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
This also required changing SkiaSalGraphicsImpl to have sk_app::WindowContext
as an internal detail inaccessible to the base class, since the Mac
implementations cannot use it as is.
Change-Id: I2424f0b887c79ee91c3bd0f1477b0745f9540247
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120909
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I7a9abde4101164af8c47433acfa35f4f9d3b3d04
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120907
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Needed at least for 'recent documents' icons in the Mac menubar.
Change-Id: I5a22cf64ff5c5aba2c70ca2556fd0b66c425bafd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120811
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
There may be still small problems (CJK needs checking), but this is
already usable.
Change-Id: Ic9381c22ca55d9e6320152ffebeae740fd90f796
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120810
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Ie91e48cb315d8e11508f064a6dcd9fafebb39abd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120809
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I01fdb57815dc3dff6d2c5757b55445f16825ed20
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120807
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
This is needed for the Skia backend to know the geometry.
The Mac Skia code now passes most VCL unittests.
Change-Id: I6e35764d95ce821d8e11ed9979e5be75bcf6ff49
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120806
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
It doesn't yet blit to screen, but the basics should be there.
Change-Id: I0f77b66756f578d84d0cee16cda00e7a2fea714f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120805
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I0bad93927248e5d8d19a69661a1b243e55791fd9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117889
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This is quite some trial and error, but now it seems all CJK text
rendering works properly. I tested tdf#136081, tdf#137907, tdf#103785,
tdf#106295, tdf#114209 and tdf#141715.
Change-Id: I40e893f66281b0a1a0e814feec3f782ceeb0c535
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115620
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
We get width+height, for vertical text width is the font "height".
This means we need to use two different fonts, one for "normal"
glyphs and one for vertical glyphs.
Change-Id: I9d190fc28286055a18c3d5c3ec75515c7c1d4373
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115618
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I0701b15a28ab3583586c0c8018c511e100b41a93
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114948
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
This is what https://bugs.chromium.org/p/skia/issues/detail?id=11810#c1
suggests (although I consider it to be an annoyance having to do this
explicitly).
Change-Id: I3df80374492c7b208ebaf819c0b4794ba535aa53
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113979
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
The conversion costs a little bit and it was done for each drawing.
Change-Id: Ifaad42308213f15839d9277beb837d21535bfc25
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113735
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
This changes all backends to use PixelFormat as the input to
the SalBitmap::Create method (and all the backends). This is the
first part as we need to make sure to also limit the use of
GetBitCount method and also use of it in SalGraphics.
Change-Id: I8d2b6adfcb8fe3dd78010538411f338c9a1c3996
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113603
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
The original idea for delayed scaling was that if a bitmap is to be
scaled, only the parameters will be saved and the pixel buffer
mBuffer will be resized only on-demand. But this gets complicated
by mImage sometimes not being just a cache of mBuffer, but sometimes
it is the only data. This is needed so that e.g.
OutputDevice::GetBitmap() can operate only on SkImage without
possibly ever needing a conversion to the pixel buffer, thus even
keeping the data only on the GPU in the Vulkan case.
Together with delayed scaling this means that the size of mImage
can be either the original size (if Scale() is called with mImage
already valid) or the final size (if mImage is created in
GetSkImage()). Thus relying on 'mPixelsSize != mSize' as
a detection of pending scaling does not always work for mImage.
Handle this by using mImage dimensions in cases where relevant.
Change-Id: Id9fad67b8936d2266c1f270d08023d15efee3987
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112545
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Iac42ead2bfd5a2b7f245cc44634f675a559d86ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112543
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I0a58f7dda3406509344d791a5e24df22a69b2478
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112179
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
E.g. the document in tdf#140753 has a PNG which technically has
an alpha channel, but it's actually completely opaque. Doing this
avoids having the pixel data for the separate alpha bitmap, and
it also avoids the pointless (somewhat costly in the raster case)
alpha blending.
Change-Id: I0916962e5894a111002c667a2f98782765aacb1f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111893
Tested-by: Luboš Luňák <l.lunak@collabora.com>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Including chrome/m89, which wasn't included before because of
tdf#140023.
Change-Id: I64f1de8e10eab2d92a9383ce8104be5afca40101
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111792
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
