I.e. those created with vcl::BackendCapabilities::mbSupportsBitmap32 set.
But there are quite possibly many more places that do not expect
that the Bitmap itself would contain alpha.
Change-Id: I83db37b3d346f42565f96b9bbf81c71b97b6bf8b
...following up on 314f15bff0 "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>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I0968cfd6a94c20e6b0d324f068ca658d7d5c0296
Reviewed-on: https://gerrit.libreoffice.org/83294
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
In preparation of writing a test for semi-transparent shape text.
Change-Id: I2dac94a6cd9da48de9a5e407ceab78fb8be933d7
Reviewed-on: https://gerrit.libreoffice.org/83264
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
To mitigate the dangers of silently breaking ADL when moving enums into unnamed
namespaces (see the commit message of 206b5b2661
"New loplugin:external"), note all functions that are affected. (The plan is to
extend loplugin:external further to also warn about classes and class templates,
and the code to identify affected functions already takes that into account, so
some parts of that code are not actually relevant for enums.)
But it appears that none of the functions that are actually affected by the
changes in this commit relied on being found through ADL, so no adaptions were
necessary for them.
(clang::DeclContext::collectAllContexts is non-const, which recursively means
that External's Visit... functions must take non-const Decl*. Which required
compilerplugins/clang/sharedvisitor/analyzer.cxx to be generalized to support
such Visit... functions with non-const Decl* parameters.)
Change-Id: Ia215291402bf850d43defdab3cff4db5b270d1bd
Reviewed-on: https://gerrit.libreoffice.org/83001
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
... is completely parsed
it might happen the element's id the url points to hasn't been parsed yet
Change-Id: Ia92c9188de5d23f2f992846aa91f3f936aeefacb
Reviewed-on: https://gerrit.libreoffice.org/79118
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
The implementation of TextSimplePortionPrimitive2D::getB2DRange in
drawinglayer/source/primitive2d/textprimitive2d.cxx can return an empty B2DRange
(which is represented internally as a huge square with DBL_MIN/MAX coordindates)
and adding that to maExtractedContour would later cause
> include/tools/helpers.hxx:76:44: runtime error: 1.79769e+308 is outside the range of representable values of type 'long'
> #0 in FRound(double) at include/tools/helpers.hxx:76:44
> #1 in ImplPolygon::ImplPolygon(basegfx::B2DPolygon const&) at tools/source/generic/poly.cxx:474:30
> #2 in tools::Polygon::Polygon(basegfx::B2DPolygon const&) at tools/source/generic/poly.cxx:1849:72
> #3 in TextRanger::TextRanger(basegfx::B2DPolyPolygon const&, basegfx::B2DPolyPolygon const*, unsigned short, unsigned short, unsigned short, bool, bool, bool) at editeng/source/misc/txtrange.cxx:67:40
> #4 in std::_MakeUniq<TextRanger>::__single_object std::make_unique<TextRanger, basegfx::B2DPolyPolygon&, basegfx::B2DPolyPolygon*, int, unsigned short, unsigned short, bool, bool, bool>(basegfx::B2DPolyPolygon&, basegfx::B2DPolyPolygon*&&, int&&, unsigned short&&, unsigned short&&, bool&&, bool&&, bool&&) at /home/sbergman/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/bits/unique_ptr.h:930:34
> #5 in SwContourCache::ContourRect(SwFormat const*, SdrObject const*, SwTextFrame const*, SwRect const&, long, bool) at sw/source/core/text/txtfly.cxx:252:13
when processing such a DBL_MAX = 1.79769e+308 coordinate while loading
doc/ooo106646-2.doc (i.e., 3sem-program-electricity_and_magnetism.doc attached
at <https://bz.apache.org/ooo/show_bug.cgi?id=106646#c13>).
Change-Id: I7bcdf7fdb3a756d7fab0543697efeb8f92ceddb7
Reviewed-on: https://gerrit.libreoffice.org/76261
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This adds drawing the wave line (typically used to underline the
wrongly spelled words) with bezier curves. Previously the wave
lines were drawn with drawing pixels, which didn't look that good,
especially on HiDPI display, so the looks of wave lines now is
therefor much better.
The creation of the wave line as a polygon has been added to the
basegfx module, so it can be reused if needed.
In addition, everytime we draw the waveline, we have to enable
antialiasing, to have a much better quality of the curves. By
default the antialiasing is disabled for some reason.
This also adds ScopedStates.hxx file which currently includes
ScopedAntialiasing, which sets the antialiasing to a certain state
for the time the object is in scope, and then sets it back to the
original state.
Change-Id: I4b866fc5d69725eb7f6f78a1acf4176b1205aa73
Reviewed-on: https://gerrit.libreoffice.org/74810
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Use it instead of classname::getImplementation from UNO3_GETIMPLEMENTATION_*
Change-Id: Ifcc8cfcd6369c576250008c76ce31ba79ea3a596
Reviewed-on: https://gerrit.libreoffice.org/74107
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Regression from 5c23459245
If statement was removed while getOptionsDrawinglayer().IsAntiAliasing()
condition still stands
Change-Id: I33baf1975436d0f917d14bf5df8232dafba92793
Reviewed-on: https://gerrit.libreoffice.org/73762
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Replace with UNO3_GETIMPLEMENTATION* macros.
Replace single usage of IMPL_XUNOTUNNEL_MINIMAL with it's body.
Change-Id: I7d4ad76399b999ebb2178ecf57edcf6bd2aa6c3e
Reviewed-on: https://gerrit.libreoffice.org/73424
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
.. hori/vert lines only"
This reverts commit f8b4d371ed. Tomaz
considers this ugly and it's no longer needed since commit
93abdf39b0 (sw lok: assume no windows in
SwLayoutFrame::PaintSwFrame(), 2019-05-14).
Conflicts:
basegfx/test/B2DPolygonTest.cxx
Change-Id: Ia9b29921ff3e5d82085e1abf9f39c172357a5e13
Reviewed-on: https://gerrit.libreoffice.org/72297
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
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 1fefdd6f3b ("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>
By creating deleted methods for the wrong calls.
Avoids the compiler needing to construct a temporary
Change-Id: I3b8c648d6bb22d22827bf74f21ea5a2a17fc0f6a
Reviewed-on: https://gerrit.libreoffice.org/72103
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
For one, it seems this was the intention already since commit
85c70f37b5 (CWS-TOOLING: integrate CWS
aw063, 2009-03-04): "suppress AntiAliasing for pure horizontal or
vertical lines".
For another, this fixes the TileCacheTests::testTileWireIDHandling()
testcase in online.git, which assumes that the indicators at the corners
of the Writer body frame (paragraph marks hidden / default case) can be
painted multiple times, producing pixel-by-pixel matching results. But
in reality AA breaks that assumption, and we know these indicators are
never diagonal lines.
Change-Id: Ib74f823165799991296b64cee58ec106dbdcedcf
Reviewed-on: https://gerrit.libreoffice.org/72000
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Improve the conversion method to do something reasonable with
empty Rectangle.
Use the conversion method in more places.
Change-Id: I48c13f3d6dae71f39f03f7939101e545c8125503
Reviewed-on: https://gerrit.libreoffice.org/71853
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
This is the first step of refactoring Animation where it is needed
to separate AnimationBitmap(s) from the Animation class, which
is also responsible for displaying of animation.
General idea is to make Graphic work only with AnimationBitmaps,
which can be freely be swapped out and in, make copies - all
transparantly from the actually displaying them and possibly it
will also remove the need to copy the animation objects.
Change-Id: If5d55ac1a5b26c3880d4f7602be57742b086f9da
Reviewed-on: https://gerrit.libreoffice.org/71406
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
These areas are zero when you start to draw a 3D object with the mouse.
Change-Id: I003ec06b42351b5c4b2b59b9f908fb82ab6e9b35
Reviewed-on: https://gerrit.libreoffice.org/71373
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
We probably don't need salbtype.hxx include, but if we do we can
now change it with a more specific one - namely BitmapPalette.hxx
in most cases. This doesn't yet touch the includes in VCL.
Change-Id: Ie3067ccb2eec425650b41ce7fca48e368215f489
Reviewed-on: https://gerrit.libreoffice.org/70761
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
