on modern hardware, these are less efficient than regular alpha
channels.
Also, this greatly simplies the range of stuff that vcl needs to deal
with, which will make the upcoming transparency->alpha patch easier to
deal with.
Enhance vcl::CreateFromData to convert incoming 1-bit data to 8-bit
image.
Change-Id: I35829da750029fe373d0d2911a669d10bab6ad23
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145321
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
to ease the reading of code related to an upcoming patch to convert
transparency to alpha, since there is already a GetAlpha in Color.
Change-Id: I1af0f8f6dd94acfe4673c8556c7aff6c20da3f7a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145209
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
i.e. ignore system theme so we get the same results on export to pdf
regardless of the theme (esp dark) and don't follow the system theme
when hosted with a writer/calc/impress document (do continue to use
system theme for StarBasic dialogs as seen in BasicIDE)
Didn't reuse 'NativeWidgetLook' for this because is currently defaults
off, while we currently do use the colors derived from the system theme
even when this is off, its really the NWF flag to render using the
platform theming engine
Change-Id: I816d7ebaf793e5eac7bd937d44c1db0371145199
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140942
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
...so that its TOOLS_WARN_EXCEPTION can be used in
comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it,
rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The
comphelper module is sufficiently low-level for this immediate use case, so use
that at least for now; o3tl might be even more suitable but doesn't have a
Library until now. Also, for the immediate use case it would have sufficed to
only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION,
TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of
include/tools/diagnose_ex.h into an additional new
include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move
the complete include file as is.)
Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...where a signed and an unsigned value are compared, and the signed value has
just been proven to be non-negative here
Change-Id: I20600d61a5d59d739bc1bee838c0038e4611aec2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134875
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Flush() turns into a sync() on the device, which is pretty slow.
Most of the time all we actually want to do is to flush the internal
buffers from the SvStream.
So expose the FlushBuffer method and use that where possible.
And also means we don't need the mbDontFlushOnClose flag on SvStream
any more.
Change-Id: Ibe089b88b325f0fdc565200a97ce72cd26b7fcfb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128214
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
in favour of the existing get*() methods.
The get*() methods 0 or false or empty in the case of "null", which
is exactly the same behaviour as the conversion methods.
These implicit conversion methods cause lookup problems when combined
with some upcoming OUString changes.
And the code looks cleaner this way too, and has less magic when calling
methods.
Change-Id: Ieb4756bf693e83b996a32667fc1b955f89193496
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125690
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The scenarios are:
1. Calling sequence's begin() and end() in pairs to pass to algorithms
(both calls use getArray(), which does the COW checks)
2. In addition to #1, calling end() again when checking result of find
algorithms, and/or begin() to calculate result's distance
3. Using non-const sequences in range-based for loops, which internally
do #1
4. Assigning sequence to another sequence variable, and then modifying
one of them
In many cases, the sequences could be made const, or treated as const
for the purposes of the algorithms (using std::as_const, std::cbegin,
and std::cend). Where algorithm modifies the sequence, it was changed
to only call getArray() once. For that, css::uno::toNonConstRange was
introduced, which returns a struct (sublclass of std::pair) with two
iterators [begin, end], that are calculated using one call to begin()
and one call to getLength().
To handle #4, css::uno::Sequence::swap was introduced, that swaps the
internal pointer to uno_Sequence. So when a local Sequence variable
should be assigned to another variable, and the latter will be modified
further, it's now possible to use swap instead, so the two sequences
are kept independent.
The modified places were found by temporarily removing non-const end().
Change-Id: I8fe2787f200eecb70744e8b77fbdf7a49653f628
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123542
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The dbase filter requires dbaccess and connectivity but I don't want
to pull in the rest of the stuff that --disable-database-connectivity
currently disables that we still don't need for fuzzing if
--disable-database-connectivity is removed
Change-Id: Ia48d42295f9724b4dd2d3beb8e46ed23fc789f5c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122579
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Noel Grandin