Age | Commit message (Collapse) | Author |
|
ImplCreateSwapInfo changed to createSwapInfo.
Flatten the code body
Change-Id: I5865373d0b7f3cc717a9600bcf6fd198e8320e35
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92947
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Iec0227b1e1ceebda961e158315ea5e56c2d33204
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92946
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I882d30f2f27149c865160b3fa68fa974701cea71
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92921
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I895002aa31380d2b5bc2593e66080f3fc94034e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92920
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Started to fixing typo "DEFINITON"->"DEFINITION",
eventually #pragma
Change-Id: Ie7617b33671614b3ac09907d380f2ffdd9b68bdb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92734
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I83a61da7dda6c72552eecd377f1c3744c92a797e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92909
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ida7ecf82d9e54d3a3703b836870534dbf41e51ba
|
|
Change-Id: I49dd552010d008cc486c6aaf51e226cc5bf4a1cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92908
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Ie235b6d02582d4d5ee3dc3d9d2be7f022bcb13c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92906
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I4ad08decf432a890cdf7acf475d15210ba813f76
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92903
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
regression from
commit e5230535877e30c3b874495e8794faa3a42d8017
Date: Tue Mar 17 21:34:21 2020 +0200
simplify ORefVector code
where a half-finished patch of mine snuck into another patch.
Change-Id: I01f59a9d451f4535197d3abd7b37bfdbc8461c15
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92901
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id6197d72ae136da04dfb22c847623004b797d75d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92840
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7ba901c7d6e1e88d9d2821df4a37ebbea3b63084
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92874
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Performing the delayed scaling for the bitmap data could keep
around cached mImage with a different size. Which theoretically could
be kept around and resized later, but the bitmap data scaling finishes
the delayed scaling by discarding all the data about it (scaling
quality), so the later resizing wouldn't know how.
Change-Id: I6a817d87becd44214f0f4db0755731b6e4ae1409
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92846
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Iec5de34f908ac370302ab51a33f17dfc23ea2446
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92834
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ieec5099a8ce9fa3f07e36be244071efc1b101cf7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92803
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I260b37a847887c79645db8015938f8bbbe6772d0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92591
Tested-by: Jenkins
Tested-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
and update pches accordingly
Change-Id: I411712532fd85961bffe6678416fcdc1d9c7f53d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92617
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Name of files:
vcl/inc/font/OpenTypeFeatureDefinitonList.hxx
vcl/source/font/OpenTypeFeatureDefinitonList.cxx
Class names:
OpenTypeFeatureDefinitonListPrivate
OpenTypeFeatureDefinitonList.hxx
Change-Id: I5feb8ccc818b84b1b777b5b1e82c0a32a898aa72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92581
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
The code previously applied the xor operation after each drawing,
but the bugdoc draws a large number of polygons in xor mode,
so the xor drawing was done repeatedly. Do the xor drawing just
once when leaving the xor mode.
Change-Id: I6c8d1c2f01688dc957a0af75232ee9fb69fe5d1b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92558
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
and recalculates them, set them correctly to begin with
Change-Id: I55735c1982a972cb76caca95363820beb2be350a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92492
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I529052c1ba7591d91d3848080af8b06e077b6f14
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92409
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic2ddff3e22a667af992d6b0701f43d3a89153458
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92371
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
the problems with GtkComboBox we have are:
1) https://gitlab.gnome.org/GNOME/gtk/issues/1910 has_entry long menus take
forever to appear (tdf#125388)
on measuring each row, the GtkComboBox GtkTreeMenu will call its
area_apply_attributes_cb function on the row, but that calls
gtk_tree_menu_get_path_item which then loops through each child of the menu
looking for the widget of the row, so performance drops to useless.
All area_apply_attributes_cb does it set menu item sensitivity, so block it
from running with fragile hackery which assumes that the unwanted callback is
the only one with a
2) https://gitlab.gnome.org/GNOME/gtk/issues/94
when a super tall combobox menu is activated, and the selected entry is
sufficiently far down the list, then the menu doesn't appear under wayland
3) https://gitlab.gnome.org/GNOME/gtk/issues/310
no typeahead support
4) we want to be able to control the width of the button, but have a drop down menu which
is not limited to the width of the button
5) https://bugs.documentfoundation.org/show_bug.cgi?id=131120
super tall menu doesn't appear under X sometimes
In general we often pack a lot into the comboboxes and the default ones don't
like that.
Overlay scrolling is turned off for the GtkTreeView replacement because
otherwise there are null-derefs in gtk on indicator->scrollbar on repeated
reopenings
Change-Id: I1b6164020996377341b5992d593a027b76021f65
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91990
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
SvImpLBox::GetCurrentEntry was identical to GetCurEntry
Change-Id: I2ede6ecd8516a2a76fe504e30b5195f3950b340e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92294
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
More flexible dialog
logo & about images as SVGs
Change-Id: Icefa035893e241a7dee6aa28236e6b89b38477de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91908
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
This has little to do with the text window used by Help -> Help.
Change-Id: I68e6870cbc0b1653e673981517c63d8c26371745
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92227
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This speeds up the loading of the bugdoc:
- old cost: 6378 ms
- new cost: 1891 ms (30% of baseline)
Images were initially loaded at import time, but commit
acb803b730f2c6bd82e39beab58949ec14f85eb0 (tdf#125591 DOC import:
lazy-load metafiles with explicit size, 2019-06-11) changed this, so
that they are lazy-loaded. That improved performance, but sometimes gave
incorrect results.
Then commit d8371cdfd092c6426c01aae130ea4eaa6d627a6f (tdf#127446 vcl
image lazy-load: fix custom size handling of metafiles, 2019-09-30)
fixed the correctness problem, but the loading was no longer lazy in the
tdf#131496 case.
This is an attempt to bring back lazy-loading for vector-based images,
while maintaining the correct preferred size.
The problem was that the PPT import triggered a vector -> bitmap
conversion during load:
#0 0x00007ffff03c7e36 in ImpGraphic::loadPrepared() (this=this@entry=0x1f88a90) at vcl/source/gdi/impgraph.cxx:1424
#1 0x00007ffff03c72c7 in ImpGraphic::ImplSwapIn() (this=0x1f88a90) at vcl/source/gdi/impgraph.cxx:1444
#2 0x00007ffff03c7535 in ImpGraphic::ensureAvailable() const (this=this@entry=0x1f88a90) at vcl/source/gdi/impgraph.cxx:1402
#3 0x00007ffff03c9481 in ImpGraphic::ImplExportNative(SvStream&) const (this=0x1f88a90, rOStm=...) at vcl/source/gdi/impgraph.cxx:1590
#4 0x00007ffff03bf9a8 in Graphic::ExportNative(SvStream&) const (this=this@entry=0x20534e0, rOStream=...) at vcl/source/gdi/graph.cxx:544
#5 0x00007ffff1c79a28 in svt::EmbeddedObjectRef::SetGraphicToContainer(Graphic const&, comphelper::EmbeddedObjectContainer&, rtl::OUString const&, rtl::OUString const&)
(rGraphic=..., aContainer=..., aName="Object 1", aMediaType="") at svtools/source/misc/embedhlp.cxx:773
#6 0x00007ffff1c79b6f in svt::EmbeddedObjectRef::AssignToContainer(comphelper::EmbeddedObjectContainer*, rtl::OUString const&)
(this=0x207ae90, pContainer=pContainer@entry=0x1f8de40, rPersistName=...) at svtools/source/misc/embedhlp.cxx:369
#7 0x00007ffff239f736 in SdrOle2Obj::Connect_Impl() (this=this@entry=0x20734f0) at svx/source/svdraw/svdoole2.cxx:984
#8 0x00007ffff23a6310 in SdrOle2Obj::Init() (this=this@entry=0x20734f0) at svx/source/svdraw/svdoole2.cxx:695
Try to defer that conversion by not doing a
maVectorGraphicData->getReplacement() in ImpGraphic::ImplSetPrefSize(),
rather just store the preferred size and apply it later when
getReplacement() is called.
This helps, because the above OLE-from-PPT case loads the graphic, but
only to export it as SVM, so it doesn't need a vector -> bitmap
conversion otherwise.
Change-Id: I24790c0a3e298d5fbb3faff35d529e79cc72845a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92144
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
There is no need to hide std::shared_ptr<VectorGraphicData> type
under an alias name. It doesn't make the code more understandble
and it usually is the exact opposite because we know with what
type we are dealing with.
Change-Id: Iec80ee99697ff2fe3a8275fc2787b5370510ebe6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92069
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Apparently it's hard for users to find out the actual Vulkan driver
version (as compared to the marketing version), which is needed
for blacklisting. And raster performance is noticeably better
if Skia is compiled using Clang. So just dump the info to
<cachedir>/skia.log (where on Windows the <cachedir> should be
AppData\Roaming\LibreOffice\4\cache).
Change-Id: Iafbc32637579b831275c60554f064479a326b917
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91980
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Ibfb6206751126def10905bb22effbe1a947cd6d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91968
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
CopyBits() wasn't reporting 'src' if it was different from 'this'.
Put the 'O' for offscreen after 'G' or 'R', so that it doesn't look
like 0 being part of the size.
Add pointer value to the Idle instances debug name.
Change-Id: I001f4265696ff2b15e0273b3ae0c3857b39e2a0a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91835
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
I came across this when seeing UITest_calc_tests2's
tdf118189.tdf118189.test_tdf118189 fail on Linux with SAL_USE_VCLPLUGIN=gen and
also on Windows, see the mailing list thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2020-April/084822.html>
"Linux SAL_USE_VCLPLUGIN=svp and the clipboard". That email thread clarified
that the codified behavior of that non-LOK test was wrong. (While the LOK test
ScTiledRenderingTest::testMultiViewCopyPaste in
sc/qa/unit/tiledrendering/tiledrendering.cxx keeps working as intended.)
I did not find documentation for what arguments CreateClipboard shall support,
but things seem to work if anything but empty arguments is rejected with an
IllegalArgumentException.
Change-Id: I1918254cc15878ad43b8aa22aff7eb1c4bea73fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91869
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
AlphaMask doesn't need any conversion to gray, it's just enough
to make sure the alpha channel bitmap is 8bpp. And the conversion
is needed for the separate-OutputDevice-alpha hacks, where
GetBitmap() gives non-8bpp bitmap for the alpha contents, but there
all the R,G,B channels are the same, so just take red and avoid
pointless conversion.
Change-Id: Ib30fc8fa6d05067d582402ab2c0fcfb49a3742f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91772
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
SkImage::MakeFromBitmap() shares the pixels instead of copying,
so in raster mode this saves some work.
Change-Id: I89aa86c269c4b4f24e305dec390ae0f80e2537da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91769
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
This allows doing the scaling at least in some cases on the GPU.
Pending scaling is detected by mSize (logical size) != mPixelSize
(actual size of pixel data).
Change-Id: I8adef13750c195fdbe48c9167737a0c31cda66d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91767
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I350cbdf753f3d6f61623e384c4446c9c6890f041
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91745
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
after
commit d9e478330243cbd120f2de33df3333fec2ef9217
Date: Fri Apr 3 10:16:22 2020 +0200
loplugin:finalclasses in xmlsecurity..UnoControls
Change-Id: Ia6566d33b4a2d6c81e009f8baebce8367bba2486
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91641
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Rene Engelhard <rene@debian.org>
Tested-by: Rene Engelhard <rene@debian.org>
Tested-by: Jenkins
|
|
Change-Id: I8e942bf37c9173a01bef6e1403ca21f579e7f608
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91612
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I69c5b28636806e45d7ba5d8c4678caeda09caa50
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91607
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I906234a38b96c6ba6eaadf7693abd33e98debf50
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91567
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If49cb7b6c3d385cc7d74fbcb0791bfb27d0be8d3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91318
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
Change-Id: I0ec68d40dcc34075c72c0d60d3a4b6e8262a8e0f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91152
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
This is maybe a Qt bug. Calling QClipboard::setMimeData from
Qt5Clipboard::setContents after a previous call to
QClipboard::clear results in a clipboard ownership failure.
In a terminal you'll see: "QXcbClipboard::setMimeData: Cannot set
X11 selection owner".
Calling Application::Reschedule() after the clear() doesn't help.
The result is a de-sync between the LO's clipboard state and the
real clipboard state, which will lead to a crash on LO shutdown.
I'm not sure this fix is correct. Maybe this could also be handled
by some X11 flush operation. But it's the only working solution I
could find: don't clear, if LO re-claims the ownership later.
I tried to reproduce the ownership error by modifying the Qt
fridgemagnets example, adding some QClipboard::clear and
QClipboard::setMimeData calls to the drop handling, but couldn't
reproduce. Maybe the dynamic Qt5MimeData object is also involved.
Change-Id: I32b6575a78a4b10a2e2b7b189303ab3a40dc69ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90990
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
The bug is most likely caused by some code checking only the OpenGL
setting and doing something, even though the Skia setting takes
precedence. So make sure VCL OpenGL is considered disabled if Skia
is enabled.
Since isVCLOpenGLEnabled() is called right before setting up
the X11 visual, which is normally needed by isVCLSkiaEnabled()
to get Vulkan info to check blacklisting, this also requires using
a temporary Skia Vulkan context using the default X11 visual
to avoid the dependency loop.
Change-Id: I2d9d9e81ab4ed5021b5f42e3c272dcd10fd32cce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91044
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
warn: sal.osl:19830:19830:sal/osl/unx/module.cxx:162: dlopen(instdir/program/libvclplug_genlo.so, 257): instdir/program/libvclplug_genlo.so: undefined symbol: _ZTI20FreetypeFontInstance
This was originally done in commit
781c4402f1a8c64f87bc81e866bc444b9ed97948 (make some classes
module-private, 2019-11-02), but it did not cause problems till
recently.
I guess this started to be a problem when the gen vcl plug started to
interact with freetype directly in the skia case.
Change-Id: I05ef0ff4446de32deccff6d7ee1fde991e5a0256
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90995
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I486922d0652f26fa7ee56f5fe308e19fe5ff137e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90856
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I40eeee44df9a089d8406199314c33d08496f41e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90838
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
See https://bugs.documentfoundation.org/show_bug.cgi?id=100706#c1
Change-Id: I2e471f093ce18c8716108c4ba793c2124e489295
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90850
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
so modifications to the model in a callback can't mangle
DragFinished's expectations.
Change-Id: I9831bbe4fe9c969307c0e7da06d579ddfa22978c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90720
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|