Reduce potential confusion with the global tools namespace. Will
hopefully make it possible to remove the annoying initial :: when
referring to the global tools namespace. Unless we have even more
tools subnamespaces somewhere.
Thorsten said it was OK.
Change-Id: Id088dfe8f4244cb79df9aa988995b31a1758c996
Reviewed-on: https://gerrit.libreoffice.org/42644
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
so it doesn't get removed again from sal/inc/pch/precompiled_sal.hxx
(see commit 4af9612f2b).
Also make necessary changes to some of the files that start to fail
building after running bin/update_pch.sh, so that the patch is
self-contained and leaves the tree in fully functional state.
tools namespace had to be prepended with :: to disambiguate from
drawinglayer::tools
vcl/inc/window.h includes were amended, because ExtTextInputAttr is
from vcl/commandevent.hxx, and enum class ShowTrackFlags is from
vcl/window.hxx
Change-Id: I47179622350754cba2f95d26a1bafd3dfbbc935b
Reviewed-on: https://gerrit.libreoffice.org/42559
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
We're on par with the old functionality now (modulo a few smaller
issues); overall QoS is much better, we get vector output on pdf
and print, and the need for large offscreen bitmap rendering goes
away.
Change-Id: I1fa92c5cad67579c3fcfa78f1bc68696bf1623ec
Reviewed-on: https://gerrit.libreoffice.org/41406
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Patrick Jaap <patrick.jaap@tu-dresden.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
More unifications, changed all Map*() methods to use a single
B2DHomMatrix which is created based on former stuff, XForm now
completely replaced. To check, added debug-only code and switches
to the VclPixelProcessor so that visual checks get easy when
using these modes (overlay of both methods with modded colors).
Also resynched to master.
Change-Id: I7b749f90bfde2ec1c2e49ee90ca2ef368da0547e
Borderline display with direct paint and with primitive direct
paint has quite some errors in the current state. Started to
unify usages, check deeper with creation/usage.
borderline: deep changes to BorderLine
Found basic error in determining the offset values
for BorderLinePrimitive creation, these were not
centered on the lines. Corrected that. This makes
it possible to remove the formally used clipping
which seems to have been used to correct that. Also
allows to go back to a 'normal' decomposition that
creates line primitives as expected. That again can
then be painted quite normally.
Also added view-dependent case to the decomposition
to guarantee a gap of one discrete unit (pixel).
Removed the direct painter, too. Checked and corrected
stroking.
borderline: Adapted previews to primitives
Added code to use the primitive representation in
all dialogs and apps using tables. The edit views
use these mostly, so the preview should do that,
too. Currently missing is a good visualization of
diagonals, but this is also true for edit views.
Checked all apps and table usages to not get worse
borderline: correct line dash visualization
When a dashed line is used, a factor of 10.0 was applied in the
original coded, added that. Also the orientation of vertical
borders was inverted since it was simpler to exchange Start/End,
but this also mirrors the line dash visualisation, corrected that
Change-Id: I4c1b380a76cb37389fab1259a53fb7cc9da982d1
e95e246d5563360617a2a2213e4d5ec7d0e736b9
62369b4de58fb0264aeb710ec6983ceddca5701d
77418cc6c84ebb0632f8c3448976e82ce612d6b6
b4eb28dc86ce05eb89b26517167305b994158ef8
borderline: adapt cppunittest and clang
Mostly generated using
make check COMPILER_EXTERNAL_TOOL=1 CCACHE_PREFIX=clang-rename-wrapper RENAME_ARGS="-qualified-name=Rectangle -new-name=tools::Rectangle"
Except some modules have their own foo::tools namespace, so there have
to use ::tools::Rectangle. This commit just moves the class from the
global namespace, it does not update pre/postwin.h yet.
Change-Id: I42b2de3c6f769fcf28cfe086f98eb31e42a305f2
Reviewed-on: https://gerrit.libreoffice.org/35923
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
if we are a hairline along the very right/bottom edge
of the canvas then distory the polygon inwards one pixel right/bottom so that
the hairline falls inside the paintable area and becomes visible
Change-Id: Ie5713f6916cf5b47fdf14f86f034e38cda9900fd
Reviewed-on: https://gerrit.libreoffice.org/34243
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
instead of returning a Primitive2DContainer from each method which we
are then going to immediately append to another container, pass down a
single container by reference which we can append to
Change-Id: I0f28a499d2ec54f7111a7044c30099767aa079e1
Reviewed-on: https://gerrit.libreoffice.org/30258
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
See svg bug doc, which is processed quite slowly. Beyond needing faster
renderers, there is also demand to improve the handling of primitives
created by SVG import.
Conflicts:
drawinglayer/source/primitive2d/patternfillprimitive2d.cxx
vcl/win/gdi/gdiimpl.cxx
Change-Id: I10992a5746b8b2d6b50e3ee3fe415a035685c9ba
The property stroke-miterlimit is transported to the renderers
via a new member mfMiterMinimumAngle in class LineAttribute
Several drawPolyLine methods are adapted. This patch does not
include changes in MetaAction. Presentation mode, printing, and
PDF-export is still wrong.
Corrected LineJoinMiter to LineJoinBevel in canvas, that s closer
to NONE. Removed DrawPolyLine method without MiterMinimumAngle
and adapted calls accordingly.
Change-Id: I6bcd24add5d85c4d9a39e3788e0682091c5fc9c4
Reviewed-on: https://gerrit.libreoffice.org/23946
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
Regression from commit 2c91cb08d6 (better
drawing support for borders of different width, fdo#33634, 2012-04-04),
the problem is that previously the width of inner/outer double border
lines got rounded to integer values quite early, but after the commit
they are kept at a double precision for much longer, which needs pixel
correction in VclPixelProcessor2D.
Example: if the border with is 1.47, and the line gets moved by 0.2
pixels, then the inner and outer edge of the line will be 0.2 and 1.67,
which gets rounded to 0 -> 2 in the pixel processor. Previously the
input was rounded to 1, so moving by 0.2 resulted in 0.2 -> 1.2, which
got rounded to 0 -> 1. The result is that sometimes the line width is 1
pixel wider than expected.
Fix the problem by allowing VclPixelProcessor2D to request pixel
correction from BorderLinePrimitive2D. It wouldn't be possible to do
pixel correction only in VclPixelProcessor2D, as it has no idea what to
correct: it only gets polygons, so it has no idea if e.g. the top of a
polygon is the outer edge of a top border line or an inner edge of a
bottom border line.
Change-Id: I1971f3a952fbcdc598ab46c659e12d976c13cbe6
Reviewed-on: https://gerrit.libreoffice.org/24221
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
probably not much performance benefit, but it sure is good at
identifying leftover intermediate variables from previous
refactorings.
Change-Id: I3ce16fe496ac2733c1cb0a35f74c0fc9193cc657
Reviewed-on: https://gerrit.libreoffice.org/24026
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
A ridiculously fast way of doing this is:
for i in $(pcregrep -l -M -r --include='.*[hc]xx$' \
--exclude-dir=workdir --exclude-dir=instdir '^
{3,}' .)
do
perl -0777 -i -pe 's/^
{3,}/
/gm' $i
done
Change-Id: Iebb93eccbee9e4fc5c4380474ba595858a27ac2c
Reviewed-on: https://gerrit.libreoffice.org/22224
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
when used as a mutable data-structure. Plain std::vector halves the time
taken to display the chart dialog
Create a class to represent the std::vector we are going to be passing
around, and move some of the utility methods into it to make the code
prettier.
Also create an optimised append(&&) method for the common case of
appending small temporaries.
Change-Id: I7f5b43fb4a8a84e40e6a52fcb7e9f974091b4485
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>
Regerssion from:
6a3fb868b2
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>
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
RenderPolygonStrokePrimitive2D draws a simple hairline if the
line width is less than 1.0 (and less than 1.5 if no AA is used)
so in tryDrawPolygonStrokePrimitive2DDirect we need to reflect
this behaviour - otherwise the lines are drawn too small.
Change-Id: Icd3d8f35a00346b1d624b6df010f43ed21968d04
Fix all sorts of incorrect double line handling in drawinglayer in order to
draw thick-thin double line types correctly. Also change handling of border
lines in writer tables. There are still some outstanding issues but it's
much better than how it was before.
Also realized that Word and Excel handle simple thin double lines differently;
Word varies widths of all of the lines and the gap whereas Excel only has one
fixed size for its double line. For this reason I decided to add a separate
double line type (DOUBLE_THIN) to handle Excel's double line.
Change-Id: Iaaa353b6e4f998b524262bea59260b4333e0cdb4
