Age | Commit message (Collapse) | Author |
|
Bit count for the image is a numeric value (sal_uInt16) but only
a handful of values make sense - namely 1,4,8,24 and 32. This
replaces the numeric value with an enum, which only accepts those
values and checks the correct values are used at compile time.
Change-Id: I0fc137c62bce3b0d021f05019a1648da628521bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112408
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
6e35794cad555485955c3b43593497dcdbf29840 changed a warning
on doing so to an assert, so I think removing this is the same
that the other test changes in that commit do.
Change-Id: I63b3eb57a42a37e6b607648ab0ae0fb4c56c97e3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111397
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I57e5a8f28a40994b61ab0f554401e4f70c8ffc12
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111230
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I72cc28d4df8031e322daa50d79666cabcb6421a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108040
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: Id13869138a622e62d9ffebf2c89bddccda6aff01
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108238
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Split class functions into BitmapInfoAccess.cxx, BitmapReadAccess.cxx
and BitmapWriteAccess.cxx
Split header files into BitmapInfoAccess.hxx and BitmapReadAccess.hxx
Change-Id: I7dcbe1d26c5b64d297658a6b809c93d7ad7f053d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108039
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Ia162ad5b7499c0ddfdbfca59ae76b81335ce2d45
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105728
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
|
|
Change-Id: Ie708250f970f2ce08c8c89e4bf001a5df23b99bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106015
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
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>
|
|
Change-Id: Ice1055021e8568634e9a66ba89d3bb4ef4e731df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104522
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If7fbb25037343e18081a8ee7064840d75e9a45a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104010
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I768aa9bd87913bc20351fb631a6326fe01f777b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103748
Tested-by: Jenkins
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>
|
|
This extends the VCL backend unittest to check for this, and also
fixes Skia to handle that properly.
This makes tdf#132241 slow again. The problem there is that it
does drawGradient() with xor enabled (for whatever strange reason),
and since Skia does not implement drawGradient(), it gets drawn
using polygons and their bounds overlap, causing applyXor() after
each operation again. Implementing drawGradient() will handle that.
Change-Id: Ibea433ad95f8c6d53049f4a49295e57a5aec184f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103280
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
And tweak the tests so that the default VCL algorithm actually passes.
Also allow a slight inaccuracy for the starting and ending white and
black colors, as the upcoming Cairo and Skia implementations are not
precise there.
Change-Id: I93bae57c0e168027a52ced0d757ee6925cb5335a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103281
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I271cc67ecf34acbf0edbda960e33315fb6a1f9dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100041
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id3471e2812f2b710d71e748e3542bc8c49dbb7a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98720
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Id5efe7227f3c2bcb5ef6f1b990327e72014e8c47
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94857
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Do like other VCL backends do.
Change-Id: I64b5d5a2fb131b41c70aa63eaf84022e9aa9fab5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94702
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
This can be seen with widget styles that use invert() to draw focus
rectangle, such as with VCL gen or win backends.
Change-Id: I7fb36d1be5333e917f871f8504585e32abe82b5a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91380
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Iab35a8b85b3ba1df791c774f40b037f9420a071a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86708
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The blendBitmap()/blendAlphaBitmap() stuff coming from the OpenGL code
is some undocumented crazy stuff (probably because the VirtualDevice
alpha handling itself is rather crazy). Hopefully I've finally figured
it out to work properly for Skia too. This separate alpha handling
all over the place in VCL should be just nuked.
Change-Id: I82615a9be7064e9ade00ec4970a131a80a543c14
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86488
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I57eb88b7b6bb498253639867d4c158041d8299b7
Reviewed-on: https://gerrit.libreoffice.org/84561
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
At least Skia and OpenGL use POST_PAINT priority for flushing drawn
contents to the screen. Using the higher REPAINT priority here could
mean that actually showing the contents would not happen. Also,
at least with Skia+Vulkan, it seems that Skia could queue commands
indefinitely, eventually running out of resources.
Change-Id: Ia3969bad18d710b006325a0fba11dc318ff93786
|
|
Mostly warnings from the 'casttovoid' Clang plugin, which is rather
annoying here.
Change-Id: I3d69697143f690211cdd26d1b9a4c0efe9397197
|
|
They already exist and are used by the unittest. And the TrackFrame
test actually appears to expect incorrect results (or otherwise pretty
much all backends implement the operation incorrectly).
Change-Id: I26867a2d1b0f01b5e836131932b422cb8823fb5b
|
|
Having them the same can hide problems with them fixed up incorrectly.
And it also shows that drawPolygon() with line color unset does not
draw the right-most and bottom-most line, which is what all underlying
graphics systems do, so the test is kind of wrong and I've added
a compensation to make it visually correct (and match the checked
expected result).
Change-Id: I333f41210232c74ba55bd5c92ef5fda917ce3e59
|
|
Not much point in showing the FPS if there's an upper limit on it
and many backends can reach it.
Note that with SAL_USE_VCLPLUGIN=gen this needs also
SAL_HIGHPRIORITY_REPAINT=1 in order to get the maximum FPS.
Change-Id: I18705bae81585d46bcaad658cc0c0c2158d89c30
|
|
This forces a blending of an alpha virtualdevice with a BitmapEx
which has an alpha component. This tries a fast-path with using
blendAlphaBitmap in the backend and does blending manually and
slower if the fast-path is not available.
Change-Id: I7e45dc78ce3e61ede408aa8388802a193cbc577a
|
|
Change-Id: I74c428b9b31b89536e72d53e418fc11b3f7e4e32
|
|
Change-Id: Idd06da27e405a3c0040bdad69c76537f12e50c92
|
|
Change-Id: I8cb3e97de79cbd683a266b09fb7d194c07b0089f
|
|
Change-Id: I6e754e72ff698d62c493b827f9804f63d0e39e2d
|
|
Change-Id: I1a2ef490ad0ae6f431f8b4c40c27c7829c51e08d
|
|
All backend tests are not enabled yet as none of the backends pass,
but testDrawInvertWithRectangle and testDrawInvertN50WithRectangle
should pass with skia backend.
testDrawInvertTrackFrameWithRectangle is more complicated as
drawing an inverted dashed frame around overshoots outside of the
rectangle area (as with gtk3 backend, maybe others too). This is
something we need to fix or better yet to get rid of this invert
mode.
Change-Id: Ibc08ff99d91014c41324b67e8e984111bcd3c7ac
|
|
...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend
loplugin:external to warn about enums".
Cases where free functions were moved into an unnamed namespace along with a
class, to not break ADL, are in:
filter/source/svg/svgexport.cxx
sc/source/filter/excel/xelink.cxx
sc/source/filter/excel/xilink.cxx
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx
All other free functions mentioning moved classes appear to be harmless and not
give rise to (silent, even) ADL breakage. (One remaining TODO in
compilerplugins/clang/external.cxx is that derived classes are not covered by
computeAffectedTypes, even though they could also be affected by ADL-breakage---
but don't seem to be in any acutal case across the code base.)
For friend declarations using elaborate type specifiers, like
class C1 {};
class C2 { friend class C1; };
* If C2 (but not C1) is moved into an unnamed namespace, the friend declaration
must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see
C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither
qualified nor a template-id and the declaration is a function or an
elaborated-type-specifier, the lookup to determine whether the entity has been
previously declared shall not consider any scopes outside the innermost
enclosing namespace.")
* If C1 (but not C2) is moved into an unnamed namespace, the friend declaration
must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882>
"elaborated-type-specifier friend not looked up in unnamed namespace".
Apart from that, to keep changes simple and mostly mechanical (which should help
avoid regressions), out-of-line definitions of class members have been left in
the enclosing (named) namespace. But explicit specializations of class
templates had to be moved into the unnamed namespace to appease
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of
template from unnamed namespace using unqualified-id in enclosing namespace".
Also, accompanying declarations (of e.g. typedefs or static variables) that
could arguably be moved into the unnamed namespace too have been left alone.
And in some cases, mention of affected types in blacklists in other loplugins
needed to be adapted.
And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which
is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is
not moved into an unnamed namespace (because it is declared in
sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about
such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler
doesn’t give this warning for types defined in the main .C file, as those are
unlikely to have multiple definitions."
(<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The
warned-about classes also don't have multiple definitions in the given test, so
disable the warning when including the .cxx.
Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4
Reviewed-on: https://gerrit.libreoffice.org/83239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: If863d28c6db470faa0d22273020888d4219e069e
Reviewed-on: https://gerrit.libreoffice.org/74559
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: I2d5ab9fd1117a4c57eb42ca849daf0949a79ff50
Reviewed-on: https://gerrit.libreoffice.org/73999
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Platform-specific subdirs are left alone:
android, ios, osx, quartz, win
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Icbb906b7fbc960240c73c56d3dae2a78b06a0f53
Reviewed-on: https://gerrit.libreoffice.org/73754
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
BitmapColor itself is kept to distingish the Color usage as part
of a color palette, which continues to store the offset in the
blue value. The original special mbIndex handling is long gone
since commit 1fefdd6f3b41 ("Alpha channel in BitmapColor - change
bIndex to alpha"), so there is no data difference.
This also results in the following changes:
* now has a basic_ostream<charT, traits>& operator<<
(that was my actual starting point... for an other bug fix)
* there is a minimal difference for GetLiminance
BGR(29,151,76) => BGR(28,151,77)
* no more return values for Merge and Invert
(previously returning *this)
* replaces all GetBlueOrIndex with GetIndex
This leaves one "problematic" part: the GetColorError handling.
At first glance it should probably be virtual. The Color variant
is less strict then the BitmapColor one - for whatever reason.
BitmapColor is always used to search for the best match in a
Palette. Currently I'm simply leaving both variants. Would be
nice to have an explict for functions here.
Change-Id: I251ba3024a1d60f2a9d9fde9cd0a60f08e8322a7
Reviewed-on: https://gerrit.libreoffice.org/72181
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: Ibd28b8fa92e98ebeb482a9081fbeae24defe4adb
Reviewed-on: https://gerrit.libreoffice.org/70826
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This (finally) adds backend tests as CPPUNIT tests too. In the
future they'll also be added into LibreOffice directly as a way
to test if the backend is OK, which will be useful especially
for the OpenGL backend, which draw quality depends on the driver.
Currently all the tests are ignored because of the bugs in the
backend, which need to be addressed first and tests then can
be enabled one by one.
The main reason for the test is to identify issues when drawing
is done at a wrong position, which is a very common problem. Also
other types of tests will be added in time, which will have a big
role in the refactoring of VCL that will happen in the future.
Change-Id: I92237d47d49fa0db01b73b8bc39f7a621b65961e
Reviewed-on: https://gerrit.libreoffice.org/70769
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I530b81b3258a6e1c1456da53bfe1285f14aee712
Reviewed-on: https://gerrit.libreoffice.org/70734
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic307226591ff9702957ccdec486ccf70357eb6d9
Reviewed-on: https://gerrit.libreoffice.org/65951
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iaa255b39928ac45dec1ed37e368c149d6027f561
Reviewed-on: https://gerrit.libreoffice.org/62701
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
Change-Id: Ia0a19736dfd4500bb17b04c072710f8ee8744031
Reviewed-on: https://gerrit.libreoffice.org/60526
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...warning about (for now only) functions and variables with external linkage
that likely don't need it.
The problems with moving entities into unnamed namespacs and breaking ADL
(as alluded to in comments in compilerplugins/clang/external.cxx) are
illustrated by the fact that while
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
returns 1, both moving just the struct S2 into an nunnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
namespace { struct S2: S1 { int f() { return 1; } }; }
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
as well as moving just the function f overload into an unnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
namespace { int f(S2 s) { return s.f(); } }
}
int main() { return f(N::S2()); }
would each change the program to return 0 instead.
Change-Id: I4d09f7ac5e8f9bcd6e6bde4712608444b642265c
Reviewed-on: https://gerrit.libreoffice.org/60539
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I1072642be4fdfa720e61f2d7bad3c2701eb81610
Reviewed-on: https://gerrit.libreoffice.org/60430
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I69247498e13331f6ef84afeb242479f8fb1178a8
Reviewed-on: https://gerrit.libreoffice.org/60068
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|