I9431c460cade3d432cb7abf76930e23f8106a7f1 ("tdf#168462 svx: mark the
slide background as an artifact") left page decoration reaching its
/Artifact by a lie: VclMetafileProcessor2D emitted one only for a
background image, and dropped a tag naming NonStructElement, so the
tag claimed to be a Division and an image. Decoration now says so
itself: the artifact decision reads the decorative flag, and the
caller passes NonStructElement and no image and means them. A
background image keeps its own path to an artifact.
isTaggedSdrObject() becomes opensStructureElement(); its comment
still claimed every one of these primitives comes from an SdrObject.
The exported file is unchanged. The one call that goes away with the
old predicate, alternative text on a tag that opens an artifact,
could not reach the file either: setAlternateText writes nothing
without m_bEmitStructure, and checkEmitStructure() is false inside a
NonStructElement. operator== now compares the element and the
decorative flag, which decide what comes out and were not compared.
Letting a master slide's own shapes out as artifacts does not follow
from treating every background as decoration. A background object can
hold tagged children, and a Paragraph begun inside an artifact opens
no marked content at all; tried on testTdf135192, three pieces of its
content came out in no marked-content section. Something narrower has
to tell the two apart.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: Id0fc0d9bee36e8182702d77e9ac9647709a63f68
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/12321
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 9353a1cac3e8056d175acc29dbeecc79ff1cdcd4)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211170
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
We added a rectangle using PolygonHairlinePrimitive2D to the
HiddenGeometryPrimitive2D, so we can mark the boundary of the
SVG image. The problem with using the hairline primitive for this
is that the hairline size is grown by 0.5 in each direction
(implGrowHairline, which is called in getB2DRange), which also makes
our SVG size 1px bigger than it should be.
Using FilledRectanglePrimitive2D instead fixes this problem as the
rectangle isn't grown in size.
Also needed to change a lot of tests that were using SVG images
and asserted the size of the image in ome way.
Change-Id: Ic2aa98b3df1f0746e4cfbd3474b6a93d0f4072ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200440
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit aa2c07951b565cd5464a36a2b0721f888ab8531c)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200433
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Replace include guards with #pragma once in drawinglayer headers
under attribute/, geometry/, processor2d/, processor3d/, tools/.
Change-Id: Ib638a2602ecb60d62dafb556f480b0955c33858c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204556
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
this was skipped in previous runs, since it contains some code behind #if
After inspecting these, it seems like the removals should not cause trouble.
Change-Id: If1e3e3c7c0fc14ed6e8b51174a0e7f1220fdbc8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197496
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
use a condition_variable to speed up termination,
or we could spend up two seconds waiting to join the background thread
Change-Id: I775a21f01eb55c7529304b5a9da3db157610be83
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192904
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The BufferedDecompositionFlusher thread is waiting for the SolarMutex
and has accumulated a bunch of rtl::References to Primitive2Ds in
aRemoved[1|2] created from direct pointers to Primitive2Ds during the
earlier phase.
Thread 6 (Thread 0x7fd2e27fe6c0 (LWP 3729389)):
#0 0x00007fd313d3012b in () at /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007fd313d364da in pthread_mutex_lock () at /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007fd3140a75f1 in osl_acquireMutex(oslMutex) (pMutex=0x556f87223470) at sal/osl/unx/mutex.cxx:93
nRet = 32723
#3 0x00007fd30e02be53 in osl::Mutex::acquire() (this=0x556f87223968) at include/osl/mutex.hxx:63
pInst = 0x556f87223830
__PRETTY_FUNCTION__ = "virtual void SvpSalYieldMutex::doAcquire(sal_uInt32)"
#4 SvpSalYieldMutex::doAcquire(unsigned int) (this=0x556f87223960, nLockCount=1) at vcl/headless/svpinst.cxx:376
pInst = 0x556f87223830
__PRETTY_FUNCTION__ = "virtual void SvpSalYieldMutex::doAcquire(sal_uInt32)"
#5 0x00007fd312bcd4fc in comphelper::SolarMutex::acquire(unsigned int) (this=<optimized out>, nLockCount=nLockCount@entry=1) at include/comphelper/solarmutex.hxx:86
__PRETTY_FUNCTION__ = "void comphelper::SolarMutex::acquire(sal_uInt32)"
#6 0x00007fd312bcd6bd in osl::Guard<comphelper::SolarMutex>::Guard(comphelper::SolarMutex*) (this=<optimized out>, pT_=<optimized out>) at include/osl/mutex.hxx:137
#7 0x00007fd312bccd53 in drawinglayer::primitive2d::BufferedDecompositionFlusher::run() (this=0x7fd2d4159230) at drawinglayer/source/primitive2d/BufferedDecompositionFlusher.cxx:154
aGuard = {pT = 0x556f87223960}
aNow = {__d = {__r = 64556205175663173}}
aRemoved1 = std::__debug::vector of length 1155, capacity 2048 =
The active thread 1 asserts that the reference count of a
SimpleReferenceObject isn't zero during dtor.
Thread 1 (Thread 0x7fd2e2fff6c0 (LWP 3726667)):
#21 0x00007fd313c2760a in salhelper::SimpleReferenceObject::~SimpleReferenceObject() (this=this@entry=0x7fd2d62f51f0, __in_chrg=<optimized out>) at salhelper/source/simplereferenceobject.cxx:29
#22 0x00007fd312bcbc57 in drawinglayer::primitive2d::BasePrimitive2D::~BasePrimitive2D() (this=this@entry=0x7fd2d62f51f0, __in_chrg=<optimized out>) at drawinglayer/source/primitive2d/baseprimitive2d.cxx:34
#23 0x00007fd312bcc368 in drawinglayer::primitive2d::BufferedDecompositionPrimitive2D::~BufferedDecompositionPrimitive2D() (this=this@entry=0x7fd2d62f51f0, __in_chrg=<optimized out>) at drawinglayer/source/primitive2d/BufferedDecompositionPrimitive2D.cxx:69
#24 0x00007fd310300136 in drawinglayer::primitive2d::SdrGrafPrimitive2D::~SdrGrafPrimitive2D() (this=0x7fd2d62f51f0, __in_chrg=<optimized out>) at svx/inc/sdr/primitive2d/sdrgrafprimitive2d.hxx:29
#25 0x00007fd310300141 in drawinglayer::primitive2d::SdrGrafPrimitive2D::~SdrGrafPrimitive2D() (this=0x7fd2d62f51f0, __in_chrg=<optimized out>) at svx/inc/sdr/primitive2d/sdrgrafprimitive2d.hxx:29
#26 0x00007fd312bcc5d3 in salhelper::SimpleReferenceObject::release() (this=<optimized out>) at include/salhelper/simplereferenceobject.hxx:83
#27 0x00007fd312bd1e63 in rtl::Reference<drawinglayer::primitive2d::BasePrimitive2D>::~Reference() (this=0x7fd2d62f4b10, __in_chrg=<optimized out>) at include/rtl/ref.hxx:126
#28 std::destroy_at<rtl::Reference<drawinglayer::primitive2d::BasePrimitive2D> >(rtl::Reference<drawinglayer::primitive2d::BasePrimitive2D>*) (__location=0x7fd2d62f4b10) at /usr/include/c++/12/bits/stl_construct.h:88
#29 std::_Destroy<rtl::Reference<drawinglayer::primitive2d::BasePrimitive2D> >(rtl::Reference<drawinglayer::primitive2d::BasePrimitive2D>*) (__pointer=0x7fd2d62f4b10) at /usr/include/c++/12/bits/stl_construct.h:149
So, what if a BufferedDecompositionPrimitive2D was registered with
BufferedDecompositionFlusher, so a direct pointer to it exists.
On Thread 0 the BufferedDecompositionPrimitive2D ref count hits 0,
dtoring starts.
Meanwhile Thread 6 merrily spins its loop, creates a rtl::Reference from
the BufferedDecompositionPrimitive2D, ref count goes back up to 1.
BufferedDecompositionPrimitive2D::dtor gets around to unregistering
itself from BufferedDecompositionFlusher, but that doesn't matter
because the rtl::Reference to the primitive already exists in aRemoved,
dtor hits assert that refcount isn't 0
Change-Id: Iac0a03bb7cbadf949ba1ac00d69cf15cc2505e18
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192674
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
This is the same thing I did in
commit 3cbe3a0259
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Mon Jun 14 15:05:59 2021 +0200
tdf#101083 speed up SVG rendering with pattern fill
but cut and paste from the VclPixelProcessor2D to the CairoPixelProcessor2D code.
Which makes this SVG render in reasonable time when using the cairo backend.
We can probably do even better by cutting out the usage of VCL here, but this
is good enough for now.
Change-Id: I959539741eef627b25702c91cad3e5f8ee2b3176
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192394
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This is follow up to commit:
commit b9f0caad5d
Author: Khaled Hosny <khaled@aliftype.com>
Date: Tue Aug 23 04:13:28 2022 +0200
tdf#66819: Disable ligatures with character spacing
Even though editengine was applying letter spacing, when drawing with
drawinglayer, letter spacing was not propagated which caused VCL to not
disable the ligature features.
Change-Id: Ia8bf2231478720262484a757e16fe5afec3cd28e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191512
Reviewed-by: Khaled Hosny <khaled@libreoffice.org>
Tested-by: Jenkins
This allows setting/using DrawModeFlags system-independent
(or: renderer-independent). Changing and applying to a
PrmitiveRenderer will apply that (if needed) to the target
renderer.
Change-Id: Id95d018f95d1b2ff065da5e4d05ba385b22cdbb0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188704
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
Did the necessary now, despite it would be better to apply
that where the geometry gets created (primitives) or painted
(older direct-apints to OutputDevice).
Instead it's in Outputevice where care is taken to apply
changes based on DrawModeFlags. Remember that this is then
done in the renderer.
This will need to be done in every renderer in the future
then. It is traditionally done in OutputDevice, completely
missing in PresentationMode and added now to CairoSDPR.
Problem is that it is not defined how to apply that, e.g.
(even in OutDev) painting text may lead to decompose and
fill the resulting polygons, so the ::*Fill flags are
applied while I think the ::*Text ones should be used.
I looked a lot at OutDev and what it does and tried to
mimic it as good as possible, but cannot give guarantees,
as mentioned in the example above.
If we assume that (as usual) the definition of what should
happen is the existing stuff when using OutDev this might
cause some further errors/regressions in HighContrast
and Black/White/Gray/Settings stuff. Luckily most of that
seems to be used in UI/Button rendering when using
OutDev, so should not lead to big problems. OTOH if
we want to use SDPRs for that in the future we would need
that anyways...
One more note: the fixes already applied may be removed
again after this is applied.
Change-Id: Ie6eb1cd4ee51c62beb950030a0a5d00d3705be61
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188527
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
In OverlayManager rendering AA state is set at the target
OutputDevice, this obviously only works if the target
renderer *is* an OutputDevice, thus not with e.g. CairoSDPR.
Thus I added changing ViewInformation2D in BaseProcessor2D
directly. This simplifies if changes to a primitive renderer
have to be made while it's lifetime.
All other aspects of ViewInformation2D can of course also
be changed. There were occasions in the past where working
around this was needed, this is then obsolete.
Since e.g. setting AA at the target renderer which
may not always be an OutputDevice makes this also target
device independent - the primitive renderer is the instance
that knows how to apply this correctly.
Change-Id: I1836d08d0844dfed81bb84e8fccbe3fabe2831c3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188220
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
there is no DeInitVCL in fuzzing, so if the BufferedDecompositionFlusher
thread is started nothing causes it to exit before _exit.
Change-Id: I62463ce8126a0cf0c67f4218bdf66a140f3a021d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184731
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
if the onShot() method is processing a lot of work, and at the same
time teardown happens, it might managed to restart itself after teardown.
What ended up being easiest is making this its own thread, and calling
shutdown() on that thread from DeInitVCL.
See notes in BufferedDecompositionFlusher.cxx.
Change-Id: I70fecb259c6e74d2c102065696f7ae2bed15cab6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183320
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
The task is fixed with the previous commit for this tdf
number, but convinced me to do also some more safe stuff
in the CairoSDPR implementation.
The associated OutputDevice *is* now handed over to
CairoSDPR and some stuff being done in the helper to
create the SDPR is now done directly in the CairoSDPR
constructors.
Also the FormControl rendering is now closer to what the
VCLPrimitiveRenderer does, to be on the safe side. It
is still just the FormControl rendering that indirectly
uses the associated OutputDevice, but more convenient.
The CairoSDPR now also (as VCLRenderer) resets the
MapMode in the associated OutputDevice for the time
using it - just in case there might be other *indirect*
usages like the FormControl one.
Change-Id: I5029788655ff81bf360d98312d417b7886208e1f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183204
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
Mike Kaganski