| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
Change-Id: I4bd549efd934946f355f06645ed816acd370a51d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126634
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.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: I1881c007a05f56d5cb7914da56243f551c2da1cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126618
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: I0c3443f182db697d12fb8bc8a356d989b62847df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126610
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>
|
|
Change-Id: Iffad4effaeef46663d8a57110bf2d560e81d0d3c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126629
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
...instead of by listing the content somewhat redundantly in the Rdb_*.mk
files, to avoid duplication of logic for components that are only built
conditionally (and thus should only be included conditionally in the
corresponding Rdb). To achieve that, add an "rdb" parameter to
gb_ComponentTarget_ComponentTarget (and to the gb_*_set_componentfile macros
that internally call gb_ComponentTarget_ComponentTarget), which is used to make
the appropriate gb_Rdb_add_component call internally from within
gb_ComponentTarget_ComponentTarget. (As a special case,
gb_CppunitTest_set_componentfile shall not call gb_Rdb_add_component, as that
has already been done by the corresponding gb_Library_set_componentfile call, so
allow the gb_ComponentTarget_ComponentTarget "rdb" parameter to be empty to
support that special case.)
Most Rdb_*.mk files are thus mostly empty now. One exception is
i18npool/Rdb_saxparser.mk, which duplicates some of the Rdb_services content as
needed during the build in CustomTarget_i18npool/localedata.
1c9a40299d328c78c035ca63ccdf22c5c669a03b "gbuild: create services.rdb from built
components" had already tried to do something similar (in addition to other
things) under a new --enable-services-rdb-from-build option. However, that
approach had four drawbacks that this approach here addresses (and which thus
partly reverts 1c9a40299d328c78c035ca63ccdf22c5c669a03b):
1 Rdb_services shall not contain the component files of all libraries that are
built. While that commit filtered out the component files that go into
Rdb_ure/services (ure/Rdb_ure.mk), it failed to filter out the component files
that go into others like Rdb_postgresql-sdbc
(connectivity/Rdb_postgresql-sdbc.mk).
2 The code added by that commit to Makefile.gbuild codified the knowledge that
there is an Rdb_services, which is brittle.
3 The code added by that commit to solenv/gbuild/Rdb.mk codified the knowledge
(for gb_Rdb__URECOMPONENTS) that there is an Rdb_ure/services, which is brittle.
4 Introducing an --enable-services-rdb-from-build option needlessly provided
two different ways how the content of Rdb_services is assembled.
The changes done here would leave --enable-services-rdb-from-build as a
misnomer, as it no longer controls how Rdb_services is assembled. I thus
renamed it to --enable-customtarget-components, as that is apparently what it
still does now.
Change-Id: Ia5e8df4b640146c77421fcec6daa11a9cd260265
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126577
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I2772e55c20d4f38d26bfe36250f4fd281d4713d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126576
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I060121b0d2b2e36cd9c5e99e3047997ed7c1d517
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126571
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I97a1868c3f086b7f414d18d0fb4daa1c6d09846f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126558
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I4ec5c5c1d5a450a0d8531907da85216000cd6c4a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126547
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
if GtkTreeView's internal do_validate_rows hasn't been run yet,
guarantee that's called by calling gtk_widget_get_preferred_width.
this is noticable in the calc autofilter color dropdown on getting
its preferred height right after inserting rows into it
Change-Id: I6dcef6ddfb462bcd9ff31ac797862804661f46fa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126491
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.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>
|
|
tdf#99919, tdf#100243, tdf#117477 and tdf#115092 are not related to slide transition
Change-Id: I41e80a6b1d025adbde7bccbedb7235d4c3c8b281
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126462
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
to find my previous attempt at this, which only obscured the problem
<noelgrandin> I'm such an idiot
<noelgrandin> I changed a whole bunch of code to avoid calling const
methods on a non-const object
<noelgrandin> from p->foo() to std::as_const(*p).foo()
<noelgrandin> can you spot the mistake?
<bubli> Is this a job interview question? :D
<vmiklos> noelgrandin: you did the opposite, now you always call const
member functions, while you wanted to always call non-const member
functions?
<noelgrandin> more like a "why didn't the smart people on this channel
tell me I was an idiot" :-)
<noelgrandin> in this case, we have o3tl::cow_wrapper, which overrides
operator* and operator->
<vmiklos> ah, and by the time you would add/remove the const,
cow_wrapper already did the expensive task of copying based on
const/non-const
<noelgrandin> exactly
<thorsten> heh
Change-Id: I5366e6a87c414b862668b61e6adfbccfdd9d3b04
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126473
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Printing still uses ExTextOutRenderer to render text because
Skia haven't yet support printing and DWriteTextRenderer can't
bind the printer DC.
ExTextOutRenderer uses win32 API ExtTextOutW. In order to
renderer upright CJK text in vertical writing with that API,
the HFONT created with CreateFontIndirectW needs a font name
prefixed with '@'. OTOH, use '@' prefixed font with Skia break
the vertical writing unit test.
- WinSalGraphics::ImplDoSetFont: use '@' prefixed font name
if the requested font is vertical and is for printing.
- ExTextOutRenderer: use SetTextAlign and text metric tmDescent
to adjust vertical glyphs. It's not consistent with Skia or
DWriteTextRenderer, and is still incorrect in many cases.
The patch is adapted from reverting
commit 5686c1aca40beb9514d40c86b4a3780a8a1334ba
Author: Mark Hung <marklh9@gmail.com>
Date: Sun May 2 14:45:45 2021 +0800
vcl: use DWriteTextRenderer for vertical writing.
Change-Id: Ib2d3df8b68cad4bebe0672c9da0a16b62aed99e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125978
Tested-by: Jenkins
Reviewed-by: Mark Hung <marklh9@gmail.com>
|
|
since we don't use OpenGL anymore for rendering,
only for slide transition (and some canvas part but it doesn't work)
Change-Id: Ia891915fcc10c0817a79e30fa59605a9681b6536
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126461
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
In my system, sizeof(long long) == sizeof(long) == 8, so multiplying
by LONG_MAX overflows long long.
Change-Id: Ieb9613ef05916ef24a64db69f698036ecaf194e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126456
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
this way scrolling in a combobox dropdown and moving the mouse outside
the widget doesn't cause the scrollbar to jump to the top. No ill
effect seen in
a) autofilter dropdowns in calc
b) color dropdown in writer main window or sidebar and clicking on
combobox subwidget to launch its popup and select an entry to
return to color dropdown
c) submenu popups from style combobox dropdown
Change-Id: I6ad445a6fab899d52907237e1f5506cce31b1f48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126408
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.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>
|
|
... and just convert the last user to $(BUILD_TYPE).
Change-Id: Iaf6361b0be47594e5c1ac08a8183460b7ada92f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126410
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
It causes tdf#146045.
This reverts commit 65081542d2dabdf17820d62abdc5a22d3734e52d
Change-Id: Id980701b1a823c8bf7cfb57e0b32cf5d672c3bfa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126373
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: Ia1c309425e64449679d6948b5e9e595fe421cfa4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126378
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
|
|
... and respect more defines. Almost just a refactoring.
Change-Id: I5d9dce742b2ef69f7f27af1970af1f8c019abfc8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126401
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
It's 2021. Something's telling me people now care more about
document previews not being blurry than an insignificant size
increase of documents. See e.g. comments #21,#25 in the HiDPI
bugreport tdf#144214. It also doesn't make much sense for the
thumbnail creation to try hard to make the image smooth and
then downscale it too much.
Change-Id: I8df778dda05cf42cd27adf8f7757097fc7650acb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126376
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I16dc352088252805a2d398620b3bbfe040a87a22
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126259
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Commit 53d51dbee6d4037c4cfc3fa743de8dac76da48c6 described it
only in the commit message, but that's hard to find if I want to
know _now_ what the thing does.
Change-Id: I012ead2aa9d81ce1287da3a32e43a038cd9ba18d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126316
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>
|
|
and indicate between rows when dropping in a visual list, which is what
we are doing for the gtk version.
a visual list case is tools, customize, menu and drag and drop the
assigned commands around.
a visual tree case is tools, macros, organize dialogs, use libraries
to create two libraries, and move to dialog and create a dialog in
one library, and drop it onto the other library to move it between
libraries.
Change-Id: Ia8dc944c1f411b1f072ad1c8dcc755a1e44e3b05
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126312
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
See also commit 5fb9f4ffa9284c7248e2e82210506babaad4044d
tdf#145964: Windows format name is FileNameW for Unicode strings
and commit 52e1d0ca6ad38b4b4fdc77b0951ad26f0ac18ec5
Windows format name is UniformResourceLocatorW for Unicode strings
We don't use other standard clipboard formats which have W variants.
Change-Id: I45afac76fe3db406c8a761f48eee9e931fd50d45
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126276
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I29c427b87aa87af3236bd6e1a7e9e08e6f470bf6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126227
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
See also commit 5fb9f4ffa9284c7248e2e82210506babaad4044d
tdf#145964: Windows format name is FileNameW for Unicode strings
TODO: replace one remaining format from CFSTR_* family that we use (see
https://www.codeproject.com/Reference/1091137/Windows-Clipboard-Formats):
FileGroupDescriptor -> FileGroupDescriptorW. That one needs more complex
handling.
Change-Id: I4d4ad83099854768cf36c7b3d89059d79c8e77f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126213
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This reverts commit 06f36cc7ca8fc056dd8cf4d8cdbe682f9a003cef
ended up not using this so don't need the extra complexity
Change-Id: I64a2d6f620cc864a75523be6612c5cf2086f7a00
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126210
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
just record the tools::Polygon so the copy on write shared polygon
is stored rather than a new instance
Change-Id: Ia2061365351457e0f0eec3be42c62063e64fdc9a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126247
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
replacement from inside real popover under x11 as in autofilter case
doesn't work.
Change-Id: Ie4ba95645a8094732b9bad9829426e77375d63ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126204
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I4761c2ae76463ad2441abf2599b69f35dc572a5c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126249
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
This introduces two concepts: a plugin and its loader (library)
LO currrently has dependency cycles for some libraries. There is
scui, which depends on sc, while sc dlopen's scui. There are the
various vclplug_*, i18npool plugins, filters/gie, acc, etc.
Usually these plugins link to their loader library, because they
use its symbols. But as a result there is no sensible way to
express the runtime dependency of loaders on the plugins.
In GNU libtool plugins are called modules and they are implemented
in an IMHO more sensible way by allowing missing symbols at link
time. This way you can have a dependency from the loader library
to its plugins, as the plugins don't depend on the loader, but you
lose the link time detection of missing symbols.
While this is in theory possible in LO too, LO currently has
plugins, like acc (accessibility), loaded by tk (toolkit), which
depends on svt (svtools), which itself depends on tk, so dropping
the tk dependency for acc on its own doesn't help :-(
And while the dependency of the plugins on their loader is fine
for the shared / DYNLOADING build, for the "static" builds you
must (somehow) link the plugins into the executables.
I also codeified a few rules into the build system along with it:
* just plugins are allowed to depend / link other plugins
* plugins aren't allowed to be linked into the merge lib
* plugin loaders are "limited" to libraries
At the high level, this is implemented via new gbuild calls:
* gb_Library_set_plugin_for,lib,loader: declare a library to be a
plugin of a loader library and add a dependeny from the plugin
library to the loader library
* gb_Library_set_plugin_for_nodep,lib,loader: ^^^^ without adding
the library dependeny
* gb_Helper_register_plugins_for_install: "plugin" replacement for
gb_Helper_register_libraries_for_install to implement some
additional checks in the build system
In the end this patch just adds a bit syntactic sugar and nothing
changes for any build.
Change-Id: I7b01d9c384cbc5838bd2cc93aff18e4868939d6e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126163
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Follow-up to commit 5fb9f4ffa9284c7248e2e82210506babaad4044d
Change-Id: I46d5ea404f77ac5ff67b6ee6a42afee13274a481
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126174
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Explicitly uses ANY, so it's hopefully easier to read then QT,
QT5 and QT6 in the otherwise same macro names.
Change-Id: Ie9bbbc858f5f9db5c8b429c7b0d8a897ac6159fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126168
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
For the static WASM build, we need to build with GUI but without
X11, as this just includes a static Qt backend.
We already have USING_X11, which indicates that the platform will
use X11 as a backend, so we can match --without-x to USING_X11=no,
independent from the --disable-gui setting.
Fitting all this into vcl/Library_vcl.mk was originally getting
quite complex, but by moving the logic into configure.ac in a
previous commit, the branching becomes way easier.
Change-Id: Ia2ddba3400b4306b609a1f64823cca75061e0593
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116125
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
And apply some of the results
Change-Id: If555476fdd951cbc1d01fb3ef3ab1cbca2b64960
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124896
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Otherwise SIMPLE_FILE clipboard format arrives encoded in ACP,
and fails for any characters not representable in ACP.
Change-Id: Ice8cfd98955e3ef49682aa21b41a313786b291f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126131
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
MACOSX is now not just the aqua VCL backend, and the Skia backend
can actually handle tests in HiDPI mode too.
Change-Id: I38ce9b7ed0a9a3a5f02a25223582bfde7b56ab9d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126148
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>
|
|
I somehow missed / forgot, that SvpInstance::DoYield was now also
yielding on the main thread and doesn't try to do "funky" multi-
threaded event processing anymore (because it's no GUI), since
commit 0efd06de8fca4036c4132b2745a11273b1755df2 ("vcl: fix hangs
in SvpSalInstance"),
So this just moves the main thread part into ImplYield and
implements DoYield like on all other architectures, as described
in README.scheduler.
I've tried to fix the LOK poll to be more sensible.
Change-Id: I4323685aa250e9d62a2f448cef358a7aa8ae862c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117899
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
we're getting slightly more lines than requested visible in f.e. the
calc autofilter drop down
Change-Id: I9ca16eb5ec6848499997a6fceec1d0ead693efce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126119
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I27c474c522554c825c0296cdf711d481d22fd024
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126126
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
