Age | Commit message (Collapse) | Author |
|
Change-Id: Ib38d3dd25f15ce403ee9ff461a94331a4a7c24ac
Reviewed-on: https://gerrit.libreoffice.org/70019
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>
|
|
Use range-based loop or replace with STL functions
Change-Id: I8594740103bdc2091c2d03d4b92bbe8393f5378c
Reviewed-on: https://gerrit.libreoffice.org/69223
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
detect static variables that can be made const.
Thanks to mike kaganski for suggesting this.
Here I introduce a new plugin feature - using markers
in nearby comments to disable the plugin for specific
vars.
Some of this stuff was old debugging code. I removed the stuff
that was older than 5 years.
Change-Id: I6ec7742a7fdadf28fd128b592fcdf6da8257585c
Reviewed-on: https://gerrit.libreoffice.org/68807
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id6ac35fefa5c3e1f64c222713791e849b3cb4d34
Reviewed-on: https://gerrit.libreoffice.org/68379
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I3db38c6294aaaa4fe6c91fac83f1f1c087398b6a
Reviewed-on: https://gerrit.libreoffice.org/66954
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ic8476ddc7805546f2f6f253f282ac976bb3b7bd6
Reviewed-on: https://gerrit.libreoffice.org/67699
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Ie4e27466c4258c6f774a3ebb82ec3a88c28fd753
Reviewed-on: https://gerrit.libreoffice.org/67525
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib748f39705cb4cee9f331e1d048a3f531116c616
Reviewed-on: https://gerrit.libreoffice.org/67242
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Id1aff2ede83e4c35976ebd51fc05aeea80dfae20
Reviewed-on: https://gerrit.libreoffice.org/67049
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Icb2f745851ba3de31f6a672d1bc20659de687d2e
Reviewed-on: https://gerrit.libreoffice.org/67031
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Ia7d6c103956c8e3cebd6ebe656fd88586d33a9c8
Reviewed-on: https://gerrit.libreoffice.org/67032
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I9ac9a34ba58f411d5aad235407553df63216319c
Reviewed-on: https://gerrit.libreoffice.org/66791
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I5bf94400d787bd57396870878d3ae7bd1e36e22d
Reviewed-on: https://gerrit.libreoffice.org/66263
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I5043c787dcc3b78bc7fdff130564801194e39f46
Reviewed-on: https://gerrit.libreoffice.org/66177
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...since b62826ad3887305a76ee1ceabe2060f9d6e8723f "Remove more unused methods"
BPixel was marked BASEGFX_DLLPUBLIC, but all its member functions are defined
inline in include/basegfx/pixel/bpixel.hxx, and basegfx/source/pixel/bpixel.cxx
was the only .cxx from Library_basegfx that included it. So on Windows, non-
inline implementations of the BPixel member functions are no longer exported
from Library_basegfx, even though code in drawinglayer using BPixel expects that
(and would thus start to fail to link on Windows). So just not mark that all-
inline BPixel class as DLLPUBLIC.
Change-Id: I7553a7ac5a57b5d175d7c81b3908ad7b80b064c3
Reviewed-on: https://gerrit.libreoffice.org/66043
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I13fbecf59e99547bbe85124dc9aa2777eef015d7
Reviewed-on: https://gerrit.libreoffice.org/66072
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...since b3c3e116ff0eb9b550b73d3901395c042e31d192 "unusedcode.easy: Removed
unused code"
Change-Id: I472af471c82676b226685bf67ee90857b6607c5e
Reviewed-on: https://gerrit.libreoffice.org/66045
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ic307226591ff9702957ccdec486ccf70357eb6d9
Reviewed-on: https://gerrit.libreoffice.org/65951
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I994910cfba1d2ec63f48094f1ef5c52226ecf322
Reviewed-on: https://gerrit.libreoffice.org/65776
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
...after 7ffdd830d5fb52f2ca25aa80277d22ea6d89970b
"HAVE_CPP_ATTRIBUTE_FALLTHROUGH is always true now"
Change-Id: I54e5ff4e036a6bb3e5774d1c0524158aae18e937
Reviewed-on: https://gerrit.libreoffice.org/64800
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I9fb8366634b31230b732dd38a98f800075529714
Reviewed-on: https://gerrit.libreoffice.org/64510
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I994a7a6c98d2e6ba32d5e005e204e9ec1f8be44b
Reviewed-on: https://gerrit.libreoffice.org/63999
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I8e90b4592d041e63bd2efa914446db96dd293ac9
Reviewed-on: https://gerrit.libreoffice.org/63964
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I041e0d04dd5a57602fd6139a2a854db243435bed
Reviewed-on: https://gerrit.libreoffice.org/63917
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
The distance between curve point and control point was calculated
as linear scaling with ratio of central angle of the arc to pi/2.
The patch replaces this with the mathematical correct formula.
Change-Id: I0195e40bb99cd4bbcce95f7ac896158b7e7e3d29
Reviewed-on: https://gerrit.libreoffice.org/63659
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The old implementation has used 4 segments and a questionable control
point distance. The patch changes this to use the common
implementation in basegfx. The method in basegfx is extended to allow
to set the start quarter, so that the custom shape circle can get the
same start quarter as it has before. The method descriptions in
basegfx are adapted to the current implementation.
Change-Id: I3a40f81827227ee0037d336bdf3c1ec6fdd64b4b
Reviewed-on: https://gerrit.libreoffice.org/63366
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
Change-Id: I1437b493f3289b4ac97d061bd71973580571e792
Reviewed-on: https://gerrit.libreoffice.org/62933
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I856345576ff5c10a41509a97ad4539272bd55568
Reviewed-on: https://gerrit.libreoffice.org/62803
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
which seem to have snuck back in since the great rounds of removals.
Change-Id: I85f7f5f4801c0b48dae8b50f51f83595b286d6a1
Reviewed-on: https://gerrit.libreoffice.org/62229
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
basctl..basic
Change-Id: I4009282869cd8a2f269093564bd4fafccab80ec3
Reviewed-on: https://gerrit.libreoffice.org/62212
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1ad7bcfa557b38488adf26b434433e6bae259f43
Reviewed-on: https://gerrit.libreoffice.org/62190
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I1d8ae37c3f3fc41d5ec65bb246e891d76f7ff544
Reviewed-on: https://gerrit.libreoffice.org/62006
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I1df70b7dff5ebb6048f7fc618789faa15ca5d422
Reviewed-on: https://gerrit.libreoffice.org/61967
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: Ifd59a5d93cfe7dc232891a681002014cd825035a
Reviewed-on: https://gerrit.libreoffice.org/61546
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
...where "inline" (in its meaning of "this function can be defined in multiple
translation units") thus doesn't make much sense. (As discussed in
compilerplugins/clang/redundantinline.cxx, exempt such "static inline" functions
in include files for now.)
All the rewriting has been done automatically by the plugin, except for one
instance in sw/source/ui/frmdlg/column.cxx that used to involve an #if), plus
some subsequent solenv/clang-format/reformat-formatted-files.
Change-Id: Ib8b996b651aeafc03bbdc8890faa05ed50517224
Reviewed-on: https://gerrit.libreoffice.org/61573
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ia26896cbcd8912f7cad641ea2ecf14c4ddf2d741
Reviewed-on: https://gerrit.libreoffice.org/61489
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I6074035ed8f90e452915e9ecffdbe9363375e126
Reviewed-on: https://gerrit.libreoffice.org/61306
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
|
|
Started to make the buffering more flexible by adding
virtual methods
virtual sal_uInt32 getHoldCyclesInSeconds() const;
virtual sal_Int64 estimateUsageInBytes() const;
to class SystemDependentData. This will allow to add more
sensitive buffering/caching.
Also fine-tuned Linux-derived classes actively used for buffering
to be more sensitive when and where to reuse the buffered data
Change-Id: Ifc69c318ade0209aff071d76001869d9f4eeb10d
Reviewed-on: https://gerrit.libreoffice.org/60881
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
|
|
This change is for speedup of fat line drawing when using
X11. This is a long-term problem which never really progressed,
but is avoided using Cairo in the future. Still - if used,
speedup using current state and buffering possibilities.
Two speedup steps will be used:
(1) The tesselation is no longer done using trapezoids. That
works (but was done wrong leaving artifacts) but is not fast
and done every time. It is even not done with FatLines and
more than 1000 points.
New version will use triangulation. Dspite using the existing
triangulator (that works but is slow) extend the FatLine
geometry creator to directly create triangles.
This is also necessary since for buffering that data a
transformation-invariant version is needed (in device coordinates
the data changes all the time when scrolling). Trapezoids are
by definition *not* transformation-invariant (e.g. rotation)
(2) Buffer that triangulation - with the needed care and watch.
It is e.g. necessary to react on 'hairlines' since these change
their logical LineWidth view-dependent (zoom). In those cases, the
buffered data *has* to be removed due to the base for buffering is
the created FatLine geometry based on one stable logical LineWidth
Also took the time to adapt B2DPolygonTriangulator to use an
own data type (B2DTriangle) and a vector of these for better
understandability and security. Adapted all usages as needed.
Change-Id: Iedb2932b094a8786fd9c32d0d0ab1ca603a1a7b2
Reviewed-on: https://gerrit.libreoffice.org/60818
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
|
|
...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>
|
|
In this step I have changed all calls that use a
B2DPolyPolygon and do filled graphics, added support for
providing needed transformation which will -if supported-
be used. Added buffering of SystemDependentData at
B2DPolyPolygon for that purpose, see comments describing
the current possibilities in the Gdiplus implementation.
Moved lifetime creation/cleanup of SystemDependentDataManager
to ImplSVData due to cleanup problems in the clang build
Tried to use a std::unique_ptr to hold the instance
of a SystemDependentDataBuffer at ImplSVData and cleanup
inside DeInitVCL() right before ::ImplDeInitScheduler. This
works in principle, but scheduler shutdown triggers
ProcessEventsToIdle which leads to repaints and re-creates
the buffer. Will now do exactly as was done with GdiPlusBuffer
before, a simple local static incarnation and a call to
SetStatic() in constructor
Splitted SystemDependentDataBuffer and Timer due to
different LifeTimes. Timer needs to be destructed
earlier than SystemDependentDataBuffer, before
Scheduler::ImplDeInitScheduler() is called from
DeInitVCL()
Change-Id: I2134e4346a183a4cee1be3428c51541cc8867c11
Reviewed-on: https://gerrit.libreoffice.org/60102
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
|
|
and use range based loops on B2DPolyPolygon
Change-Id: Ic68c236c839766a0c52369ae8487de187d1ad04e
Reviewed-on: https://gerrit.libreoffice.org/60189
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
use references to B2DPolygon where loop index is needed
Change-Id: I3b048072bac139e8e451331b832a03a1413bc9eb
Reviewed-on: https://gerrit.libreoffice.org/60223
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I08f6a64b50f03d1b08027a2ac9e51442255d64bc
Reviewed-on: https://gerrit.libreoffice.org/59976
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and consequently simplify some call-sites
Change-Id: I301fc4c88fdfb8af75a348a41593a27f4c6567c5
Reviewed-on: https://gerrit.libreoffice.org/59916
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iec140c37e437ce0b49f07b393498f0804e5b46d8
Reviewed-on: https://gerrit.libreoffice.org/59846
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
Did some changes inspired by Noel, corrected the
transformation due to mirroring already applied,
re-added 'mirror this window back'-mode
Change-Id: I21999e59898cf672fd293bc2b11f5d568e6673be
Reviewed-on: https://gerrit.libreoffice.org/59842
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
|
|
This is a first step to allow buffering of system
dependent data, especially (but not only) for the
system-dependent implementations of graphic output.
For example, for B2DPolygon and Win output, it allows
buffering the Gdiplus::GraphicsPath instead of re-
creating it all the time.
To support that, the change includes forwarding the
current transformation to the renderers in SalGraphics.
The current state in VCL is to transform all and
everything to device coordinates at every single
paint.
I have currently started to do this for ::drawPolyLine
implementations. The fallbacks for all systems will
at the start of that method just transform the data
to device coordinates, so all works as before.
This may also be done for FilledPolygon paint in a later
step, but most urgent is FatLine painting.
An arrangement of shared_ptr/weak_ptr is used so that
either the instance buffering (in the example B2DPolygon)
or the instance managing it can delete it. The instance
managing it currently uses a 1s Timer and a cycle-lifetime
management, but that can be extended in the future
to e.g. include size hints, too.
The mechanism it designed to support multiple Data per
buffering element, e.g. for B2DPolygon at the same time
system-dependent instances of Gdiplus and Cairo can be
buffered, but also PDF-data.
This is achieved semi-automatic by using
typeid(class).hash_code() as key for organization.
The mechanism will be used for now at B2DPolygon, but
is not limited to. There is already a similar but less
general buffer (see GdiPlusBuffer) that can and will
be converted to use this new mechanism.
Added vcl/headless Cairo renderer to support given
ObjectToDevice transformation (not to transform given
B2DPolygon)
Added support for CairoPath buffered at B2DPolygon,
seems to work well. Need to do more tests
Moved usage to templates suggested by Noel Grandin
(Noel Grandin <noelgrandin@gmail.com>), thanks for
these suggestions. Adapted Win usage to that, too.
Converted Win-specific GdiPlus BitmapBuffer to new
mechanism, works well. Checked, the manager holds
now a mix of bitmap and path data under Win
Added a cleanup mechanism to flush all buffered data
at DeInitVCL() using flushAll() at
SystemDependentDataBuffer
Adapted Linux-versions of ::drawPolyLine to support
PixelSnapHairline, for now in a simplified version
that still allows buffering. This will also be used
(and use buffering) for the Cairo-fallback in
X11SalGraphics
Change-Id: I88d7e438a20b96ddab7707050893bdd590c098c7
Reviewed-on: https://gerrit.libreoffice.org/59555
Tested-by: Armin Le Grand <Armin.Le.Grand@cib.de>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
|
|
Change-Id: Iffd8b0a19d4479b6c70dc834c6f64499e87e01b1
Reviewed-on: https://gerrit.libreoffice.org/59265
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Powerpoint only allows M,L,C,Z,E,m,l,c,z,e , i.e. V,H,S ( and
their corresponding relative command ) must not be used and
ending E is mandatory. Command and space delimiters also can not
be skipped.
Change-Id: Icad38ec2eed3e49143eb9a03aa56cc178baae99d
Reviewed-on: https://gerrit.libreoffice.org/58848
Tested-by: Jenkins
Reviewed-by: Mark Hung <marklh9@gmail.com>
|