Age | Commit message (Collapse) | Author |
|
Toolkits usually do not provide the ability to specify gradient steps,
which means VCL falls back to its algorithm, which at least with Skia
sometimes causes poor results.
Change-Id: I35dbf87e77d5ed36d8f257db877135a2a0be2ffe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106971
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I3720692af45920a4d084fe6ca4dd08bc0598ac13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106385
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I66f7e5602c7a47baeadccfe913b9be984f0a5177
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106384
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Move anonymous namespace into drawinglayer::primitive2d and convert
static function into anonymous functions.
Change-Id: Id8ff161a5ec69154f053fadd1178265fa2675139
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106383
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Ia80a0331246b4e25cdc3387c50bd97c6befc4ea4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106382
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I890d19f5e2177294dc1175c90c98b964347f9e85
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105751
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
To properly import some EMF files, the proper implementation of MapMode Text
needs to be done according to MS documentation.
I have also added regression tests.
Change-Id: Id788294a498b93bebb62118d13ea545f80a60f01
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105771
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I2dd9c385c89f05026227e82ce85cecbe36e2c51c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105662
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This reverts commit 8891a2fc2a4bf86add68691b7ac167a07a8add84.
Reason: Causes regression, tdf#136891
Revert #2 "-Werror,-Wunused-variable (clang-cl)"
This reverts commit a879b15d59618e73797ad779666f72cd040ff99a.
Reason: Variables are necessary for the other revert.
Change-Id: Ic1c3efe22f5c069f666ea6ba3193612cb44203ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105620
Tested-by: Jenkins
Reviewed-by: Aron Budea <aron.budea@collabora.com>
|
|
in favour of the more widely used, and better optimised, operator+
Change-Id: I6a1b37e0f3d253af1f7a0892443f59b620efea63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105523
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iefe922c2e0d605114d54673d63eccc5e4abd545d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102143
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I8f3cd05dbd86bd22fd84d767adc44fc2b0c89404
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105468
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This reverts commit f39e4b6b6f8aa8b4af22b6eb30a52e98cd5a6455.
Reason for revert: Breaks the build on Windows, see e.g.
<https://ci.libreoffice.org//job/lo_tb_master_win/28613/>
> C:/cygwin/home/tdf/lode/jenkins/workspace/lo_tb_master_win/drawinglayer/source/primitive2d/textlayoutdevice.cxx(432): error C2065: 'bFontIsScaled': undeclared identifier
> C:/cygwin/home/tdf/lode/jenkins/workspace/lo_tb_master_win/drawinglayer/source/primitive2d/textlayoutdevice.cxx(438): error C2065: 'nWidth': undeclared identifier
(<https://gerrit.libreoffice.org/c/core/+/104847/1> "Revert 'tdf#127471 Remove
font width scaling hack'" had trivially succeeded to build on Jenkins, as it was
base on the old 8891a2fc2a4bf86add68691b7ac167a07a8add84 "tdf#127471 Remove font
width scaling hack" which it reverted, rather than on recent master.)
Change-Id: I1060e5423f594894b15330ba6631a9af07a64634
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104958
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This reverts commit 8891a2fc2a4bf86add68691b7ac167a07a8add84.
Reason for revert: Causes regressions like tdf#136891
Change-Id: I940c447bec38231b666eeac4212f09e22117504e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104847
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Change-Id: Ide9811c1a7582454b3fcf655b70ea106ed56509a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104914
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
(In VisitVarDecl, filtering out AbstractConditionalOperator avoids an unhelpful
> ~/lo/core/vcl/source/pdf/XmpMetadata.cxx:63:32: error: replace single use of literal 'rtl::OString' variable with a literal [loplugin:elidestringvar]
> aXmlWriter.content(sPdfConformance);
> ^~~~~~~~~~~~~~~
> ~/lo/core/vcl/source/pdf/XmpMetadata.cxx:52:21: note: literal 'rtl::OString' variable defined here [loplugin:elidestringvar]
> OString sPdfConformance = (mnPDF_A == 1) ? "A" : "B";
> ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
)
Change-Id: I7d0410f04827d79b4b526752917c37d33cad2671
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104911
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
grepping for stuff in template params this time
Change-Id: Ia37bfd85480b3a72c3c465489581d56ad8dde851
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104855
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
(*) create a rewriting plugin to do most of the work, heavily
based on the fakebool plugin
(*) but there are still a number of "long"s in the codebase
that will need to be done by hand
(*) the plugin needs lots of handholding, due to needing to
add #include and update macros
Change-Id: I8184d7000ca482c0469514bb73178c3a1123b1e9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104203
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
partly to flush some use of "long" out the codebase,
but also to make it obvious which units are being used
for angle values.
Change-Id: I1dc22494ca42c4677a63f685d5903f2b89886dc2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104548
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
A number of powerful functions using B2D polygons such as
OutputDevice::DrawPolyLineDirect() were used only if AA was enabled.
So e.g. dashing for an AA-ed polyline could be drawn directly
using the function, but with AA disabled had to be done manually
by a number of polygon operations. Which doesn't make much sense,
surely these powerful functions can also draw without AA if set so
(and indeed that's mostly the case). And DrawPolyLineDirect() even
had a flag to bypass the check.
So simply try to use B2D-based drawing whenever possible, AA or not.
The previous commit had already changed the naming of the AA option
to not include B2D in the name.
This seems to come from https://bz.apache.org/ooo/show_bug.cgi?id=88795,
which doesn't explain why AA only. There are other bugreports such as
https://bz.apache.org/ooo/show_bug.cgi?id=101491 and
https://bz.apache.org/ooo/show_bug.cgi?id=98289 that are related, but
there I cannot see any difference with this patch. And all unit tests
pass.
Change-Id: Ibb5938e8fff9b7452bac4bf12ed3e42fd3e5d645
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103354
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
This renames AntialiasingFlags::EnableB2dDraw to just Enable,
and the AntiAliasB2DDraw names to just AntiAlias. This is
in preparation for a second commit that will actually separate
the AA and B2D functionality of these flags.
Change-Id: I9cc215c5752dfabce41e00e19d9074fc8dc3d4de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103416
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
VCL's drawGradient() can handle them all, at least using a fallback
algorithm. And drawinglayer doesn't know which of them are handled
directly by the VCL backend used.
A catch is that the rendering of tdf#133477 is different, so
keep using drawinglayer for the affected gradient types until somebody
fixes that.
Change-Id: I1719c67c15752c6d1c3431ddfa797ac94d039555
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103376
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
This adds a divert for drawing of linear gradients drawing, which
can be implemented natively with a much higher quality and speed.
This also adds a implementation of drawing linear gradients with
cairo.
Change-Id: I8c39915c3579e6eb88cdce8ae4ac9694ffdb4957
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103374
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I41a204fbc5e2c9b819fb948c5288f8d7b4195489
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103117
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
This commit was carried out by a Python script, source of which
is at https://bugs.documentfoundation.org/show_bug.cgi?id=124176#c97.
Change-Id: I196a60fda0fa88ea2d9ac438d5e9234fde46fb18
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102574
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Id4a7a15b7b88df888d2cd224e375c839c59b882f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102301
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ie584ee9bece01ea92f5cc9f21a402ae9e8319710
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102189
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I8f6a3756d48b1727f9ac64c2e162be148e1c61d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102183
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Iaab26ade1109daf732e58a2f3741cc43243e374c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102023
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: If51bf7143116721e8f16272cf8aff797651d5ed1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101880
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: If6683cd134e9bd675ec9b6f9a59fa667ebb41da0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101647
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I473956d570feac508e52a3e52cc26cc154f4dc56
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101627
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
This is a prerequisite for making conversion from OUStringLiteral to OUString
more efficient at least for C++20 (by replacing its internals with a constexpr-
generated sal_uString-compatible layout with a SAL_STRING_STATIC_FLAG refCount,
conditionally for C++20 for now).
For a configure-wise bare-bones build on Linux, size reported by `du -bs
instdir` grew by 118792 bytes from 1155636636 to 1155755428.
In most places just a u"..." string literal prefix had to be added. In some
places
char const a[] = "...";
variables have been changed to char16_t, and a few places required even further
changes to code (which prompted the addition of include/o3tl/string_view.hxx
helper function o3tl::equalsIgnoreAsciiCase and the additional
OUString::createFromAscii overload).
For all uses of macros expanding to string literals, the relevant uses have been
rewritten as
u"" MACRO
instead of changing the macro definitions. It should be possible to change at
least some of those macro definitions (and drop the u"" from their call sites)
in follow-up commits.
Change-Id: Iec4ef1a057d412d22443312d40c6a8a290dc6144
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101483
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I786548bef39fa711aabcff32b592b3fdc4a6f9fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101486
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I6f5ab6c659a7b6827c1c5f017a740173806504d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101291
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ic783ab10a3bc2139eef65351d515814374431e59
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101131
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I7ceb13e4dd247185c2d9b264e81fc5973a0da916
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101009
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I37c492adef30db748eaa975247d386dcd953257b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100949
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Which causes distorted fonts in certain cases (see bug report).
Fix was suggested by Ilhan Yesil at https://bugs.documentfoundation.org/show_bug.cgi?id=127471#c6
Change-Id: Ie644f56f0835ffad9230f981d2927d6b4c17453d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100970
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I9d55e4478d8cf3047b4ccac88e06fdc87e68e6ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100871
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
Add shadow primitive id into the switch case to run
ProcessPrimitive2DOnPixelProcessor function.
Change-Id: I059771ba4c56eca50c74aad81c4dec193b454dca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100861
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
look for expressions like
!(a && !b)
which can be expanded out
Change-Id: I72515a9638762b050f9a258c08da39ebfa2ef8e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100579
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This removes the only place that hadn't used transparent impBufferDevice
yet - in VclProcessor2D::RenderMaskPrimitive2DPixel. Not clearing the vdev
made it draw on whatever garbage was left there from previous paints when
the buffer was taken from maFreeBuffers in VDevBuffer::alloc, so since this
was also the only place left that didn't clear the buffer explicitly, this
makes the clear unconditional in impBufferDevice ctor.
Also this makes sure to clear proper rectangle in VDevBuffer::alloc, and to
clear mpAlphaVDev in OutputDevice::Erase.
Change-Id: I7c1c0cc510a92628f19020b3faf0c0cd81f5a599
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100674
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I3122a4058f5447cbf0369b60b368c76e5fe40089
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100647
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I57a47358d5e4f1e41fc1c89884b7603d8afdc3bd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100646
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I8b4e1d6654c3a75a3174d56ac01f7d0c7aea5a8d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100645
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I6b3b6ef1530a192f4b6bf87aa9688687063683ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100591
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
...now that GCC 11 trunk implements P1155R3 since <https://gcc.gnu.org/git/
?p=gcc.git;a=commit;h=1722e2013f05f1f1f99379dbaa0c0df356da731f> "c++: Implement
C++20 implicit move changes. [PR91427]", at least in -std=c++20 mode
Change-Id: Ie3c8f391fe4a6a99144ab35b2b29214ac5413fc8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99999
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
When zooming in the bitmap can become huge, requiring a lot
of processing, most of it not being used.
Change-Id: I0a4907f5cf23ab7316fed8568924fe76c744b81a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97872
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I32648ae81c4a06f944b70c0cca1694333ec02859
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98916
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|