Ito probably made sense only with bitmap fonts which we no longer
support, and if we don’t need the fallback for printer devices then we
don’t need it on screen either (that whole printer/screen distinction
needs to die someday).
Change-Id: Icf77cd70f0f1b2c186a3c856900295caba72e903
Reviewed-on: https://gerrit.libreoffice.org/31914
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>
Inspired by a recent bug report where we were assigning the result
of VclPtr<T>::Create to a raw pointer.
As a consequence, we also need to change various methods that were
returning newly created Window subclasses via raw pointer, to
instead return those via VclPtr
Change-Id: I8118e0195a5b2b4780e646cfb0e151692e54ae2b
Reviewed-on: https://gerrit.libreoffice.org/31318
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Look for places where we are accidentally assigning a returned-by-value
VclPtr<T> to a T*, which generally ends up in a use-after-free.
Change-Id: I4f361eaca88820cdb7aa3b8340212db61580fdd9
Reviewed-on: https://gerrit.libreoffice.org/30749
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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>
The problem is that the graphics cache only counts the size of the SVG
text, which is stored in SvgData::maSvgDataArray. However the
SvgData::maSequence may use a lot more memory, as it may contain
de-compressed bitmaps that are stored as base64-encoded PNGs in the SVG
text.
For example icon-themes/galaxy/brand/flat_logo.svg is 812 Ko but contains
60 Mo of bitmaps.
This may cause excessive memory usage and failure to export documents
due to OOM; according to valgrind massif, the bitmap buffers use 90% of
the heap.
Add a new interface com::sun:⭐:util::XAccounting, and implement
it in drawinglayer BasePrimitive2D. VCL SvgData can't access
drawinglayer via C++ directly so this looks like the best approach.
Change-Id: I5a7c3147733e23473c1decabed24c1f79d951c7d
Reviewed-on: https://gerrit.libreoffice.org/30669
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
I left a prefix on the names "Map" so that I would not have to re-arrange
each name too much, since I can't start identifiers with digits like "100thMM"
And remove RSC_EXTRAMAPUNIT, which doesn't seem to be doing anything anymore.
Change-Id: I5187824aa87e30caf5357b51b5384b5ab919d224
Reviewed-on: https://gerrit.libreoffice.org/29096
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
The issue of 362d4f0cd4e50111edfae9d30c90602c37ed65a2 "Explicitly mark
overriding destructors as 'virtual'" appears to no longer be a problem with
MSVC 2013.
(The little change in the rewriting code of compilerplugins/clang/override.cxx
was necessary to prevent an endless loop when adding "override" to
OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager();
in chart2/source/inc/LifeTime.hxx, getting stuck in the leading
OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that
isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.)
Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
static bools were probably used for debugging proposes
and should not be in master
introduced in commits:
9f6018ec1472d7e4f2f26b300d8c00b09fda1fe8
ddcf9b9ff2caaffcc59d250b2d7f50ca3ab20330
d45ddb6d03846b0c576eeee062342962aa131bc0
7a652a2b2ab5e0d37e32185c8c5fac3af482bb76 and
70e3eb2c1762fb1ca097cf671e3c7ce3d0dfd1b7
Change-Id: Ided2bf923696cd9fc537f1cb4fedd1a7d4b7c5cd
Reviewed-on: https://gerrit.libreoffice.org/26880
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de>
commit 4f27ff917237be96eec897d4af90a3379be904c6
Author: Tor Lillqvist <tml@iki.fi>
Date: Mon Jul 29 18:24:23 2013 +0300
Avoid SolarMutex assertion in a dbgutil build when exiting Impress
put in a SolarMutex in that ImpTimedRefDev dtor for what sounds like
just this problem
commit 9f0766917a4fb1bc8fe1786c3b46132dd63c1c66
Author: Armin Le Grand <Armin.Le.Grand@cib.de>
Date: Fri Jul 1 14:40:00 2016 +0200
tdf#50613 add support to load charts asynchronously
took it out again, to presumably move it into TextLayouterDevice
but we destroy this thing asyncronously outside of TextLayouterDevice
so lets put it back in again
Change-Id: If801a701701a3d87fce2f76bc22bb3184b46743a
If more than one place in the code submits tasks to the shared
pool, then waitTillDone() becomes unreliable.
Add a tagging mechanism, so different callsites can wait
on different sets of tasks.
Also try to protect our worker threads against exceptions from
the thread tasks code.
Change-Id: Idde664ab50008d31a2dd73910bb22f50e62ae22f
Reviewed-on: https://gerrit.libreoffice.org/27042
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Use buffering in the drawinglayer, and don't do slow stuff in the
windows gdi renderer.
Conflicts:
svgio/source/svgreader/svgstyleattributes.cxx
Change-Id: Id955ee6a3b03e568c2678f02d77af35d2e5ba1d4
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
Generating primitives for chart visualisation can be moved to a
paralell executed task that loads the chart, thus speeding up
initial visualization. This is not possible for e.g. PDF or print
targets, only for edit visualization. On fallback, the replacement
images of the charts are used which are metafiles and have less
quality as primitives, but load quicker.
Change-Id: I68caa9e1bec50832bce535b5f54633d53cdef037
