| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I35f1ca3fc703dbf31c68f4b145344b23029a156d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134688
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
To avoid this bactrace : https://crashreport.libreoffice.org/stats/crash_details/4d1984f3-3352-49fa-8569-ebf6994ed216
Change-Id: I45ae8b56191c546c551ccaf48d5ab27a20b8e0e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133662
Tested-by: Jenkins
Reviewed-by: Arnaud Versini <arnaud.versini@libreoffice.org>
|
|
If cairo is available we override drawPolyPolygon and drawPolyLine
with an implementation that uses cairo to draw instead of X11.
This override was previously done in X11SalGraphics, but as we want
to have all the drawing in backends (SalGraphicsImpl children) this
also needs to be moved to one. In this case we can just derive
X11SalGraphicsImpl and implement specifics there. As there is some
common stuff now betwee X11SalGraphics and X11SalGraphicsImpl,
also add X11Common, which includes those.
Change-Id: Id1e0c5227506e03d3dd0f937e4ef50d69b17bb22
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132827
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
(with --disable-assert-always-abort --enable-dbgutil,
<https://ci.libreoffice.org//job/lo_tb_random_config_linux/3741/>)
Change-Id: I46c4ed35e1882a98bde4022681624ae6c94031b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131664
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
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>
|
|
The minimal angle is valid only if the line join style is miter,
and e.g. FileDefinitionWidgetDraw can call these with round join
style and 0 angle, which would divide by 0. So either clamp
the value or compute it only when needed.
Change-Id: I2a2c71481490c03ec6d01b8e33cab991400adb35
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129006
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I2514e39bba8debcbdbb60929d2ca2f1ba3aaa2e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128456
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This is similar to the previous Cairo commit. Fetching pixels
from the GPU is not as slow as fetching them from the XServer,
but this still can make a visible difference. And small surfaces
should not need fast GPU rendering that much, so hopefully this
improves more cases than it regresses.
Change-Id: Ida031b38cd1ce14ded464747c20a38c6d094c5a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128310
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>
|
|
Change-Id: I6b8c815fda3a48917467719432071c0716e3e9ab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127338
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
This is a follow-up to 4a11c85baeb4998e12bc2ab45b0c23, after all
it was a driver problem. But the time 7.4 is out the newer one
working will be hopefully in sufficient use.
Change-Id: I682a56ec6e5b6dfe4c85930346177fc5c13569c9
|
|
Change-Id: I20bbb0e252ffd09901f587599430e715dbe977b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128300
Tested-by: Caolán McNamara <caolanm@redhat.com>
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>
|
|
Change-Id: Icbf19e86b833c0cec08a9ac5c41c01fd2dd1a4e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128060
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.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>
|
|
Following 2c86b79e87bc8579f5213708954d5c85fe231407
cache Skia drawing based on checksum of bitmap content (tdf#146095)
Change-Id: I184a7d96988b7a52100de026c13f422590755ded
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126635
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Tested-by: Jenkins
|
|
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>
|
|
Change-Id: Ic7781f799d0d4baef01955f03ace8428b6d9f229
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126584
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>
|
|
Canvas apparently likes to redraw only small parts of the background,
which means that there may be repeated scaling of clipped parts
of a large background image that are considered too clipped to be
cached, but even the drawing of the clipped part may add up to be
costly in the end if done often. Refusing the caching only after
checking whether the image is possibly cached may avoid some
of the drawing in case there was an initial drawing that wasn't
clipped and thus generated the cached image. Helps a bit with
e.g. tdf#136223.
Change-Id: I4de6164940ec7a06fb6ae2f504907b4fa076f1d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126412
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.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>
|
|
Apparently the call is expected to handle even copies that are
partially outside of the area, e.g. window scrolling seems to do
this occassionally.
Change-Id: I9a06c047f00d6b5b920d61f577baa9181bdc5a2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126147
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
https: //bugs.chromium.org/p/skia/issues/detail?id=12685
Change-Id: I4de51b154e270df470102c357c25bdfa430a4488
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126118
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I280b668e40d800ecd6eb03ddcda3c2ebd2dd0254
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126114
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.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: Ib89b00c3dc8cd440e8a88906eea133becd1cef64
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125509
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
Some controls draw outside of their given area, which would get cropped
when first drawing to a temporary context limited to just that size.
I haven't managed to find a way to calculate the proper marging, so
just add something that's hopefully enough but not too big.
Change-Id: I1a15a3ab8cbd26cbe4fb52628b300ee70c8d51ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125469
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Some of the control drawing calls use CGContextFillRect() to draw
background for controls, so since we use a temporary context, set
up colors for such drawing.
Change-Id: I41cfa29e29fcf86598d49fbbed0b159c48c63d6a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125468
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
This code was drawing them at non-HiDPI size and then scaling up.
Change-Id: I90abfd36adaff4e7c4929cd28d0aa50d919449a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125467
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Idd21ee0026d8a36653f0fb25b350dae37315f603
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125336
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: I2f5aa12eb656f6b337843d81a2a30de277dff7b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125410
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
This is a mistake from f33b76b4e675818deae244427cef84c576a1a1f8.
Change-Id: Iae69ae0099a62451d156c80255f55b1f6aad4725
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125370
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Ifb7c6d8a4506808b5f56492e692ef7172a367e26
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125344
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Force non-smooth scaling to get exact pixel values. Introduced
in 6792e6e5e49d11a54256b75c4c5a476bb2f10b4a.
Change-Id: Iec2633e9ef8e930688c95ceb1037696456f344f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125312
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.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: Ia1cd0522643b58ea1be3ad974c1fc5f7fed657d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125268
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Ibc78371f9e2ba92470714847bb6a5b8b96d1037f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125264
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>
|
|
It'll draw double-sized 1/4 of the content in the topleft corner
of windows, but it's still useful for some tests.
Change-Id: I20c6d2382d704ddcd67b8cb81eb7abf37b57a92f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125262
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>
|
|
[CXX] vcl/source/window/keycod.cxx
/home/julien/lo/libreoffice/vcl/skia/SkiaHelper.cxx:664:21: error: variable is only used as rvalue, should be const [loplugin:conststringvar]
const char* diff = R"(
~~~~~~~~~~~~^~~~~~~~~~
1 error generated.
From https://cgit.freedesktop.org/libreoffice/core/commit/?id=110fa313628c55fef1d35830358aea7e27c1e3ee
get rid of Skia's 'rasterhack' for Invert()
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: I721d88664f9cb03529ec6e9244424d8e3ed4d156
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125126
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
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 automated code flattening may make sense in old spaghetti code,
but this is new code, and it's structured the way it makes sense.
Both those if's are logically just a part of a larger function
and bailing out sooner is at least conceptually wrong (and the moment
I add more code there, I'd need to revert anyway).
Change-Id: Iddbd22166159429636196eb1545b008ef576036b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125054
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
