Polygon is one of these names that Clash with some system objects
A similar work has been done earlier with PolyPolygon.
Change-Id: Icf2217cb2906292b7275760f1a16be0e150312f5
Reviewed-on: https://gerrit.libreoffice.org/17789
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
This was a feature requested by mmeeks, as a result of
tdf#92611.
It validates that things that extend XInterface are not
directly heap/stack-allocated, but have their lifecycle managed
via css::uno::Reference or rtl::Reference.
Change-Id: I28e3b8b236f6a4a56d0a6d6f26ad54e44b36e692
Reviewed-on: https://gerrit.libreoffice.org/16924
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
We used it all over the place without leading :: already anyway, even
in many files in include. So let's be consistent. In the majority of
cases, prefer the easier-on-the-eyes choice, not the "safe" one.
In those files in include where *all* existing uses of ::vcl:: indeed
used the :: prefix, there let's keep it for consistency.
Change-Id: If99cb41d3bf290d38c601d91125c3c8d935e61d0
... candidate when tiled rendering. Tiled rendering works entirely in
twips, so pixel sizes are not relevant. One step closer to working image
resizing in the tiled rendering case.
Change-Id: I1d5e33071a383b333e0fdb9d30ea09fcea23a8fc
Regerssion from:
6a3fb868b2b8af21f7b6140424b6f8377599a786
The new tryDrawBorderLinePrimitive2DDirect() draws rectangles, but
borders are assumed to be trapezoids. So simple comment this
out and use the original drawing method.
Change-Id: I755d5f0b3621bfc4c999ee994a375d4e5ebbcdf0
I've renamed TryDrawPolyLineDirect() to DrawPolyLineDirect() and also
renamed TryDrawPolyLineDirectNoAACheck() to drawPolyLineDirectNoAACheck().
However, at the same time I feel that there is no need to call on
drawPolyLineDirectNoAACheck in most instances, because DrawPolyLineDirect
does an AA check before it can continue anyway. There is one instance where
constantly checking the AA check is inefficient because it's in a loop, in
that case then we call directly on drawPolyLineDirectNoAACheck, but this is
the only case it is necessary.
Change-Id: Ie0320bfc45b5c0e1ac6ce35912da3e2897af9429
Reviewed-on: https://gerrit.libreoffice.org/12190
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>
regression from
commit a5351434fbea1126961f5dbaa986e7c9e686c24e
Author: tsahi glik <tsahi.glik@cloudon.com>
Date: Thu Jan 16 12:51:44 2014 -0800
fix rendering issues in iOS with aqua
because now the cache just fills up because nothing will have
a depth of "0" and a new entry is created every time.
0 could be seen to mean "whatever is a good non-1bit depth" or auto or
something. (Do the uses of "8" really mean 8)
0 passed to new VirtualDevice under Linux/X ends up using the depth of the
outputdev, so here set nBits to that value to start with and the problem
goes away
Change-Id: I4390d6f7edef9dc7430cc77e3518dc751a5f479d
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>,
changed from a macro- to a template-based solution. (Unfortunately MSVC 2012
does not support explicit conversion operators. Worked around that with
explicit #ifs rather than some HAVE_EXPLICIT_CONVERSION_OPERATORS and
SAL_EXPLICIT_CONVERSION_OPERATOR ainticipating we hopefully soon move to a
baseline that requires unconditional support for them.)
Change-Id: I4a89643b218d247e8e4a861faba458ec6dfe1396
Put the TOOLS PolyPolygon class in the tools namespace. Avoids clash with the Windows
PolyPolygon typedef.
Change-Id: I811ecbb3d55ba4ce66e4555a8586f60fcd57fb66
Since these constants are bitfield flags, we define some methods to make
working with them reasonably type safe.
Move the definitions to outdevstate.hxx, since we need the values there,
and that appears to be the "root most" header file.
Also dump TEXT_LAYOUT_BIDI_LTR constant, since it means the same thing
as TEXT_LAYOUT_DEFAULT (ie. 0), and leaving it in causes people to write
weird code thinking that it's a real flag.
Change-Id: Iddab86cd6c78181ceb8caa48e77e1f5a8e526343
Reviewed-on: https://gerrit.libreoffice.org/10676
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
