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>
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>
The only thing that needs to be reimplemented is the pbuffer based
custom sprite rendering. We should use a FBO with a texture backend
for that. This will also save several OpenGL context switches!
Change-Id: I4aef33ae2499e44c8b5f41c296d8721cb94a37a1
Adds opengl canvas implementation - display-list-based, all
rendering done as textured geometry. Needs shader support.
Currently compiles and works on Linux, Mac should be ~easy to
add, win32 eventually.
Change-Id: Ibf3eb88d6a36a91b2960a3a6320d708160e4fc14
