| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
WARNING: ThreadSanitizer: data race (pid=271122)
Write of size 8 at 0x7244000becc0 by main thread (mutexes: write M0):
#0 drawinglayer::primitive2d::BufferedDecompositionPrimitive2D::get2DDecomposition(drawinglayer::primitive2d::Primitive2DDecompositionVisitor&, drawinglayer::geometry::ViewInformation2D const&) const /home/noel/libo-tsan/drawinglayer/source/primitive2d/BufferedDecompositionPrimitive2D.cxx:90 (libdrawinglayercorelo.so+0xb986)
#1 drawinglayer::processor2d::BaseProcessor2D::process(drawinglayer::primitive2d::BasePrimitive2D const&) /home/noel/libo-tsan/drawinglayer/source/processor2d/baseprocessor2d.cxx:43 (libdrawinglayerlo.so+0x1284cf)
#2 drawinglayer::processor2d::CairoPixelProcessor2D::processBasePrimitive2D(drawinglayer::primitive2d::BasePrimitive2D const&) /home/noel/libo-tsan/drawinglayer/source/processor2d/cairopixelprocessor2d.cxx:4230 (libdrawinglayerlo.so+0x7a370)
#3 drawinglayer::processor2d::BaseProcessor2D::process(drawinglayer::primitive2d::Primitive2DContainer const&) /home/noel/libo-tsan/drawinglayer/source/processor2d/baseprocessor2d.cxx:67 (libdrawinglayerlo.so+0x1286f1)
#4 drawinglayer::processor2d::CairoPixelProcessor2D::processMaskPrimitive2D(drawinglayer::primitive2d::MaskPrimitive2D const&) /home/noel/libo-tsan/drawinglayer/source/processor2d/cairopixelprocessor2d.cxx:1919 (libdrawinglayerlo.so+0x6fbd9)
#5 drawinglayer::processor2d::CairoPixelProcessor2D::processBasePrimitive2D(drawinglayer::primitive2d::BasePrimitive2D const&) /home/noel/libo-tsan/drawinglayer/source/processor2d/cairopixelprocessor2d.cxx:4103 (libdrawinglayerlo.so+0x7a33c)
#6 drawinglayer::processor2d::BaseProcessor2D::process(drawinglayer::primitive2d::Primitive2DContainer const&) /home/noel/libo-tsan/drawinglayer/source/processor2d/baseprocessor2d.cxx:67 (libdrawinglayerlo.so+0x1285f1)
#7 drawinglayer::processor2d::BaseProcessor2D::visit(drawinglayer::primitive2d::Primitive2DContainer const&) /home/noel/libo-tsan/drawinglayer/source/processor2d/baseprocessor2d.cxx:54 (libdrawinglayerlo.so+0x1285f1)
#8 drawinglayer::primitive2d::GroupPrimitive2D::getChildren(drawinglayer::primitive2d::Primitive2DDecompositionVisitor&) const /home/noel/libo-tsan/include/drawinglayer/primitive2d/groupprimitive2d.hxx:76 (libdrawinglayercorelo.so+0x1c51b)
#9 drawinglayer::primitive2d::GroupPrimitive2D::get2DDecomposition(drawinglayer::primitive2d::Primitive2DDecompositionVisitor&, drawinglayer::geometry::ViewInformation2D const&) const /home/noel/libo-tsan/drawinglayer/source/primitive2d/groupprimitive2d.cxx:53 (libdrawinglayercorelo.so+0x1c51b)
#10 drawinglayer::processor2d::BaseProcessor2D::process(drawinglayer::primitive2d::BasePrimitive2D const&) /home/noel/libo-tsan/drawinglayer/source/processor2d/baseprocessor2d.cxx:43 (libdrawinglayerlo.so+0x1284cf)
Previous read of size 8 at 0x7244000becc0 by thread T299 (mutexes: write M1):
#0 std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long, std::ratio<1l, 1000000000l> > >::time_since_epoch() const /usr/lib/gcc/x86_64-linux-gnu/14/../../../../include/c++/14/bits/chrono.h:950 (libdrawinglayercorelo.so+0xcd6f)
#1 std::common_type<std::chrono::duration<long, std::ratio<1l, 1000000000l> >, std::chrono::duration<long, std::ratio<1l, 1000000000l> > >::type std::chrono::operator-<std::chrono::_V2::steady_clock, std::chrono::duration<long, std::ratio<1l, 1000000000l> >, std::chrono::duration<long, std::ratio<1l, 1000000000l> > >(std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long, std::ratio<1l, 1000000000l> > > const&, std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long, std::ratio<1l, 1000000000l> > > const&) /usr/lib/gcc/x86_64-linux-gnu/14/../../../../include/c++/14/bits/chrono.h:1143 (libdrawinglayercorelo.so+0xcd6f)
#2 drawinglayer::primitive2d::BufferedDecompositionFlusher::run() /home/noel/libo-tsan/drawinglayer/source/primitive2d/BufferedDecompositionFlusher.cxx:133 (libdrawinglayercorelo.so+0xcd6f)
#3 threadFunc /home/noel/libo-tsan/include/osl/thread.hxx:189 (libdrawinglayercorelo.so+0xe0ee)
#4 osl_thread_start_Impl(void*) /home/noel/libo-tsan/sal/osl/unx/thread.cxx:237 (libuno_sal.so.3+0x6b419)
Change-Id: Ie7afe0501d0d562117fc4418a3fe24853397aefe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187238
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Moved central stuff needed for decompose to Primitives
closer to EditEngine/Outliner. There is now a
StripPortionsHelper as abstract base class with two virtual
methods replacing the lambdas used before. That is easily
implementable to all needs. Adapted all usages. Also the
methods for creating needed Primitives from DrawPortionInfo
or DrawBulletInfo is now local/private in EditEngine.
This step should still change nothing in functionality, but
is more preparation to be able to directly create Primitives
from Outliner/EditEngine setups for paint and (re)use.
Change-Id: Ie2bcebf4030128f88be229d789944cc2842eafb6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187045
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
second attempt at landing this, first attempt failed because
I did not realise that this is an "extra" transparency on top
of any transparency the image might already have.
Dramatically speeds up rendering on most backends
(the cairo drawinglayer renderer already has an optimised path here).
Change-Id: I9da67767a9aa6418eaed478ed2de7710183d53ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187053
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
regression from
commit 1f61a2ec4e252d2eeccabd65a10650c8ee231a1b
Author: Noel Grandin <noelgrandin@gmail.com>
Date: Mon May 26 13:26:19 2025 +0200
tdf#166715 speed up transparent fill operation
where I mistook "hasTransparency" to mean "does the bitmap have an alpha layer", instead of "there is an __additional__ alpha value applied to this bitmap"
Change-Id: If89d95103fc13e7ce78e7056d0a53aa40d48cde2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187034
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
Change-Id: Ib50cdbc97e24865baa077442e0dc53fb275bfef6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186727
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
See comments in code & task.
Change-Id: I6c34a86ab713130b427fd5efad83b7028a32bc19
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186721
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
For handling transparency for tiled bitmaps correctly in
metafiles the newly added linear transparency is too much
and leading to many single transprent bitmnaps. This is
not wrong but too much data and bloating the metafile/PDF.
For details and extensive explanations see text in commit.
Change-Id: I255db614e0c9eb8cd5130abbdaef4eda1c398684
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186630
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
I see failures on the mac buildbots lately that look like multithreaded access to bitmap stuff.
Turn off multithreading here if skia is active.
Stack looks like:
Fatal exception: Signal 6
Stack:
#0 0 libuno_sal.dylib.3 0x000000010b431e4c _ZN3sal13backtrace_getEj + 60
#1 1 libuno_sal.dylib.3 0x000000010b455149 _ZN12_GLOBAL__N_110printStackEi + 41
#2 2 libuno_sal.dylib.3 0x000000010b46f542 _ZN12_GLOBAL__N_121signalHandlerFunctionEiP9__siginfoPv.cold.1 + 34
#3 3 libuno_sal.dylib.3 0x000000010b454ff4 _ZN12_GLOBAL__N_121signalHandlerFunctionEiP9__siginfoPv + 740
#4 4 libsystem_platform.dylib 0x00007ff807942fdd _sigtramp + 29
#5 5 ??? 0x0000000000000000 0x0 + 0
#6 6 libsystem_c.dylib 0x00007ff807839a39 abort + 126
#7 7 libsystem_c.dylib 0x00007ff807838d1c err + 0
#8 8 libvcllo.dylib 0x0000000112cc2d23 _ZN13SkiaSalBitmap13ReleaseBufferEP12BitmapBuffer16BitmapAccessModeb.cold.2 + 35
#9 9 libvcllo.dylib 0x00000001129082f7 _ZN13SkiaSalBitmap13ReleaseBufferEP12BitmapBuffer16BitmapAccessModeb + 855
#10 10 libvcllo.dylib 0x00000001126664fd _ZN16BitmapInfoAccessD2Ev + 61
#11 11 libdrawinglayerlo.dylib 0x00000001221ee37a _ZN12drawinglayer7texture17GeoTexSvxBitmapExD2Ev + 74
#12 12 libdrawinglayerlo.dylib 0x00000001221e62bf _ZN12drawinglayer11processor3d18DefaultProcessor3D33impRenderBitmapTexturePrimitive3DERKNS_11primitive3d24BitmapTexturePrimitive3DE + 543
#13 13 libdrawinglayerlo.dylib 0x00000001221e4c38 _ZN12drawinglayer11processor3d15BaseProcessor3D7processERKNS_11primitive3d20Primitive3DContainerE + 88
#14 14 libdrawinglayerlo.dylib 0x00000001221e7049 _ZN12drawinglayer11processor3d18DefaultProcessor3D22processBasePrimitive3DERKNS_11primitive3d15BasePrimitive3DE + 249
#15 15 libdrawinglayerlo.dylib 0x00000001221e4c38 _ZN12drawinglayer11processor3d15BaseProcessor3D7processERKNS_11primitive3d20Primitive3DContainerE + 88
#16 16 libdrawinglayerlo.dylib 0x000000012218d3d7 _ZZNK12drawinglayer11primitive2d16ScenePrimitive2D21create2DDecompositionERKNS_8geometry17ViewInformation2DEEN8Executor6doWorkEv + 23
#17 17 libcomphelper.dylib 0x000000010b9e39f1 _ZN10comphelper10ThreadTask4execEv + 33
#18 18 libcomphelper.dylib 0x000000010b9e5212 _ZN10comphelper10ThreadPool12ThreadWorker7executeEv + 306
#19 19 libuno_salhelpergcc3.dylib.3 0x000000010aebe3f0 _ZThn16_N9salhelper6Thread3runEv + 32
#20 20 libuno_salhelpergcc3.dylib.3 0x000000010aebeb5f threadFunc + 15
#21 21 libuno_sal.dylib.3 0x000000010b45c151 _ZL21osl_thread_start_ImplPv + 129
#22 22 libsystem_pthread.dylib 0x00007ff80791418b _pthread_start + 99
#23 23 libsystem_pthread.dylib 0x00007ff80790fae3 thread_start + 15
Change-Id: I695e3d675f996aee6ea6b889eb78c39e4dbf509c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186632
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
which was keeping stuff alive for too long.
regression from
commit 8a17b7f0a679ebf21bcfb425186b205d996d129b
Author: Noel Grandin <noelgrandin@gmail.com>
Date: Thu Mar 13 18:37:54 2025 +0200
tdf#131595 Improve drawinglayer flushing mechanism.
Change-Id: I82c3e11d027b22a969d2ce786a0945fea2deb6b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186389
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
(gdb) print mpReadTransparence.moAccess._M_payload._M_payload._M_value.mpBuffer
$18 = (BitmapBuffer *) 0x0
#0 BitmapReadAccess::GetScanline (this=<optimized out>, nY=<optimized out>) at /opt/rh/devtoolset-12/root/usr/include/c++/12/optional:484
#1 BitmapReadAccess::GetPixel (nX=<optimized out>, nY=<optimized out>, this=<optimized out>) at include/vcl/BitmapReadAccess.hxx:83
#2 drawinglayer::texture::GeoTexSvxBitmapEx::impGetAlpha (this=this@entry=0x3a073610, rX=rX@entry=60, rY=rY@entry=420)
at drawinglayer/source/texture/texture3d.cxx:111
#3 0x00007f4cc4baba0e in drawinglayer::texture::GeoTexSvxBitmapEx::impGetAlpha (rY=420, rX=<optimized out>, this=0x3a073610)
at drawinglayer/source/texture/texture3d.cxx:152
#4 drawinglayer::texture::GeoTexSvxBitmapEx::modifyBColor (this=0x3a073610, rUV=..., rBColor=..., rfOpacity=@0x7f4cabbba638: 1)
at drawinglayer/source/texture/texture3d.cxx:152
#5 0x00007f4cc4ba9a31 in ZBufferRasterConverter3D::decideColorAndOpacity (this=this@entry=0x39db6260, rColor=...)
at drawinglayer/source/processor3d/zbufferprocessor3d.cxx:119
#6 0x00007f4cc4ba4d9c in ZBufferRasterConverter3D::processLineSpan (this=0x39db6260, rA=..., rB=..., nLine=<optimized out>, nSpanCount=<optimized out>)
at drawinglayer/source/processor3d/zbufferprocessor3d.cxx:305
#7 0x00007f4cc438d5f6 in basegfx::RasterConverter3D::rasterconvertB3DArea(int, int) ()
at basegfx/source/raster/rasterconvert3d.cxx:129
#8 0x00007f4cc4ba0ac7 in drawinglayer::processor3d::DefaultProcessor3D::impRenderPolyPolygonMaterialPrimitive3D(drawinglayer::primitive3d::PolyPolygonMaterialPrimitive3D const&) const ()
at drawinglayer/source/processor3d/defaultprocessor3d.cxx:448
#9 0x00007f4cc4b9fcc9 in drawinglayer::processor3d::BaseProcessor3D::process (this=this@entry=0x39da04c0, rSource=...) at /opt/rh/devtoolset-12/root/usr/include/c++/12/bits/stl_deque.h:263
#10 0x00007f4cc4ba1ca0 in drawinglayer::processor3d::DefaultProcessor3D::impRenderBitmapTexturePrimitive3D(drawinglayer::primitive3d::BitmapTexturePrimitive3D const&) ()
at drawinglayer/source/processor3d/defaultprocessor3d.cxx:263
#11 0x00007f4cc4b9fcc9 in drawinglayer::processor3d::BaseProcessor3D::process (this=this@entry=0x39da04c0, rSource=...) at /opt/rh/devtoolset-12/root/usr/include/c++/12/bits/stl_deque.h:263
#12 0x00007f4cc4ba2846 in drawinglayer::processor3d::DefaultProcessor3D::processBasePrimitive3D(drawinglayer::primitive3d::BasePrimitive3D const&) ()
at include/drawinglayer/processor3d/baseprocessor3d.hxx:63
#13 0x00007f4cc4b9fcc9 in drawinglayer::processor3d::BaseProcessor3D::process (this=0x39da04c0, rSource=...) at /opt/rh/devtoolset-12/root/usr/include/c++/12/bits/stl_deque.h:263
#14 0x00007f4cc4b3a225 in drawinglayer::primitive2d::ScenePrimitive2D::Executor::doWork (this=0x39e13950) at /opt/rh/devtoolset-12/root/usr/include/c++/12/bits/unique_ptr.h:461
#15 0x00007f4cc4868fe7 in comphelper::ThreadTask::exec() () at comphelper/source/misc/threadpool.cxx:319
#16 0x00007f4cc4869c61 in comphelper::ThreadPool::ThreadWorker::execute (this=0x39e13aa0) at /opt/rh/devtoolset-12/root/usr/include/c++/12/bits/unique_ptr.h:461
#17 0x00007f4cc144f33f in salhelper::Thread::run() () at salhelper/source/thread.cxx:39
#18 0x00007f4cc144fe94 in osl::threadFunc (param=0x39e13ab0) at include/osl/thread.hxx:189
#19 0x00007f4cc14e0563 in osl_thread_start_Impl (pData=0x39120800) at sal/osl/unx/thread.cxx:237
#20 0x00007f4ccae5f6db in start_thread (arg=0x7f4cabbcb700) at pthread_create.c:463
#21 0x00007f4ccab8874f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Change-Id: Ic30b38dc1c53c9df551a282c6a057d042265419e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186222
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
otherwise I see
vcl/source/outdev/stack.cxx:101: OutputDevice::Pop() without OutputDevice::Push()
Change-Id: I40ed55ed0cfa2ffea3afae51ef2b3a04f5c35497
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185960
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Transparent bitmapex drawing works fine these days, so we dont
need this fallback path anymore.
Dramatically speeds up rendering on most backends (the cairo drawinglayer renderer already has an optimised path here).
Change-Id: Ic66a4f2d76a6815d1cb3a439e416f1235be7a544
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185795
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
If the BackgroundColorPrimitive2D has a Viewport set this means
we have limitations, so render as needed/defined. This can be
done additionally by creating geometry for that range, or just
use the decomposition. To do so, just use recursion/decompose
in this case.
Change-Id: I85fe6eb78fe8d154ced99d53af40ba0d9f1049d8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185718
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
|
|
We used to have two duplicating sets: smart pointer-like VclPtr::reset,
and Reference-style VclPtr::set / VclPtr::clear. There is no need in
this duplication. Further, in ScopedVclPtr, reset is hidden / removed
to avoid skipping disposeAndClear; but the twin functions are kept
accessible, possibly as an overlook.
This change drops Reference-style VclPtr::set / VclPtr::clear, and
unifies on VclPtr::reset, which looks more consistent with the class
nature (it is closer to shared_ptr, than to uno::Reference). Doing
that uncovered one place, where a ScopedVclPtr was used incorrectly:
clear() was used for NotebookbarPopup::m_pParent in NotebookbarPopup
dtor. I assume then, that the correct class needed here is VclPtr.
Change-Id: I0746075c58d793fabdce1bc357afea8ee455cd8a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185553
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
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>
|
|
otherwise we end up renaming the main thread
Change-Id: I59f8274e13273321d80ab264e1d31e66b70547c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184318
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
found with bin/find-unneeded-includes --fwdecl
Change-Id: I61ee34a26ed75c0bbbf4dae0359bfeeea37b4296
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183883
Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
Tested-by: Jenkins
|
|
Change-Id: I1d9b05c600cea860df0596d63e817b30347f563c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183651
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Aron Budea <aron.budea@collabora.com>
Tested-by: Jenkins
|
|
now that this has stabilised, I don't need it anymore
Change-Id: Ibadd043bb11f6070ee66637e3eb0174c9bbe7a63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183596
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
when clearing objects, I have seen a crash on macos which happens inside
skia
Change-Id: I8328439917339242d56d813f518e05bbd92adc60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183572
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This patch allows to render a text object in edit mode by decomposing a
TextHierarchyEditPrimitive2D instance in place of using TextEditDrawing.
That avoids to have artifacts displayed while playing the slideshow such as a
tiny rectangle around the edited text shape.
Moreover it allows to animate a single paragraph even when the related text
object is in edit mode.
Change-Id: I0c27dc0953dd1b0fb7ae70f41e569587f3a623ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183532
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Iac558c8b653349a86966869bd96dca265a8fb223
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183419
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
|
|
Change-Id: I1f9091c47f0145d6fa0a8bc2deb4864244aad896
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183309
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
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
|
|
Change-Id: I7921dc085e348945f8f14c12a15ed6c5414f298e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183294
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and
cid#1645104 Data race condition
Change-Id: I91674b3646789cb70ddcea034f34b386c23ea95f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183257
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
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
|
|
and
cid#1645088 Data race condition
cid#1645086 Data race condition
presumably the mutex is just for maBuffered2DDecomposition, otherwise
setting maLastAccess with the mutex held implies all the other maLastAccess
uses should be protected with that mutex
Change-Id: I918b8854a2abbb8436200c98cf545e217b19bba6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183244
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
stopping the timer doesn't seem to be sufficient, try deleting all of
the contained data at that point in time too.
regression from
commit 8a17b7f0a679ebf21bcfb425186b205d996d129b
Author: Noel Grandin <noelgrandin@gmail.com>
Date: Thu Mar 13 18:37:54 2025 +0200
tdf#131595 Improve drawinglayer flushing mechanism.
Change-Id: Ic11f287e83c482bfa81b5efb6b378113d15ecd0d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183164
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
releasing the reference is not enough, we have to call stop() on it.
regression from
commit 8a17b7f0a679ebf21bcfb425186b205d996d129b
Author: Noel Grandin <noelgrandin@gmail.com>
Date: Thu Mar 13 18:37:54 2025 +0200
tdf#131595 Improve drawinglayer flushing mechanism.
Change-Id: I6686e1fb1d2509413597ce4fa88b23d99a7e047a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183133
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Which dramatically speeds up switching between sheets in
the referenced document.
The problem here is that we have a timer for each buffered primitive.
And we have a lot of primitives here.
And the TimerManager does not scale well to lots and lots of timer,
because it uses a linked list.
So this change modifies the flushing mechanism, trading off some
precision for some speed.
Change-Id: I66a744f06af9b08d4e9b797d11db8d22f4060789
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182876
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Otherwise we could be reading stale data.
And change it to return a bool, the call-sites only care if we
have/dont-have the data, and returning a value of a field that should only
be accessed under a lock is dodgy.
And move the the setRemainingTime call to get2DDecomposition(), because
that where we really "use" the data ie. paint with it.
Change-Id: I44b5d41fee68985213ecc7d11b4ce1bdcfd119b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182909
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Otherwise we could be reading stale data.
And change it to return a bool, the call-sites only care if we
have/dont-have the data, and returning a value of a field that should only
be accessed under a lock is dodgy.
And move the the setRemainingTime call to get2DDecomposition(), because
that where we really "use" the data ie. paint with it.
Change-Id: Ie795465a1177a47f846cf9310d419079e52b8770
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182908
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
If using an empty ViewInformation, it is possible that the prim.
decomposition is redone, when a different ViewInformation is used.
This removes all visibility flags for the paragraphs, so the whole
text is rendered. This fixes the issue by using the same instance
of the ViewInformation that is also used later for rendering the
primitives to the VirtualDevice, so the buffered decomposition is
used.
Also a test is added - it checks the hash of the buffer, which
should be different for all 3 layers. For this the tostring has
to be moved to the common hash.hxx, so we can reuse it in out
tests.
Includes:
Author: Marco Cecchetti <marco.cecchetti@collabora.com>
AuthorDate: Wed Mar 5 23:15:33 2025 +0100
slideshow: regression: layer with paragraph has not the expected content
Change-Id: I850c6922cdd358eee35074fbff04f238994b2c76
Otherwise 'make -C sd -sr CppunitTest_sd_tiledrendering
CPPUNIT_TEST_NAME=testSlideshowLayeredRendering_Animation_DifferentKindOfTextBox'
would fail.
Change-Id: I4c951215a52e302d3b7b60a30c1b995002e53a4b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182833
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
... and use for PDF export, instead of the representation, which appears
to be wrong.
Strangely the Hyperlink dialog already allowed to insert a Name, but it
was not actually set in the document.
(regression from commit fa3f04bdd4f73a1b3be70dfb709c44638ef7e3d9)
Change-Id: Ic21bbe8ead9f85dfbe0827b0051ecb68aeff0beb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182597
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
This one is similar to tdf#165061 due to not using CairoSDPR when
RTL is used, but it seems that not all cases of 'mirroring' are
covered with using IsRTLEnabled. It also needs to check
HasMirroredGraphics, so I added that.
Change-Id: Ia86add7841e69657d8f64f7001eea4a57e927043
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182481
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
found by a little plugin I created.
Plugin parked into store/ folder because it needs hand-holding
when run.
Change-Id: I2b4da7378f0becbc5f020ac9e78cd765aa0119b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181768
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
See comments in task, for now disable using SDPR when RTL is
enabled.
Change-Id: I9dabe2324fb9e6b190ebb3851dc73b2c7dacf84d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181604
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: I529dfdee60055cb27af2ef6ba3ae50694ac191e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180554
Reviewed-by: Hossein <hossein@libreoffice.org>
Tested-by: Jenkins
|
|
The task shows that for some situations the Controls do not
get vbisualized. These *should* be child windows of the
panel containing them, but fir some reason these seem to
get incarnated by being 'painted'.
Problem is that for SDPRs an OutputDevice to do so is not
available - by purpose. Luckily it is possible to use a
awt::XGraphics and 'paint' from there.
It would also be possible to find out why the child windows
do not get constructed and where this may need to be done,
but for now just add 'painting' the Controls by using the
path utilizing the awt::XGraphics mechanism. For that
purpose, do set an awt::XGraphics at the CairoSDPR if it
gets constructed using an OutputDevice.
It may be that we need to think about how to solve this
for SDPRs that get constructed from scratch, e.g.
when using createPixelProcessor2DFromScratch. This would
mean to somehow construct a awt::XGraphics from a cairo
surface, probably using an OutputDevice as in-betwen
step, but for now this change solves the problem.
Change-Id: I3bc653deab7f0b2902081b0fdbd501dfcc78383b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180967
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: If596f94b80ee9a7d203ccf04f74d94ff8636e069
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180891
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I88a021042ccf4e69d550a15eb9555c8f36437c8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180887
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
If Cairo Coordinate Limit Workaround is Active do
also adapt hairline width to 1.0 since we (have to)
fallback to render in view coordinates.
Change-Id: I2216c1728355b5e76ee04f699193a896f9c4fd4b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180860
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Regression after commit bc0ab08634f59e1a1814e575fe6ad5e50bf1aee1,
where I confused what neede to be rounded.
Change-Id: Ib150ea1989ed7241747fe4a89bce051478a54bfc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180737
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
"paintPolyPoylgonRGBA"->"paintPolyPolygonRGBA"
Change-Id: I9969634d9bd286c25b8c1953b1b7ddf1a4bf4629
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180654
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Id343170838639e1b3f6e762f7769a9f0b066f9be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180653
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I6cee3b0b283feff5b153301bed5a0cae2ef88eea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180652
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ia7bf5acfdc6b30f31d29d7938c419f9e26b43ec4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180657
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ieae92ec95fee8d506fde9b21ac6551e83bd2750c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180594
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Thus Cairo is offering a full-fledged double precision API but
internally uses a 24.8 fixed-float format (see https://gitlab.
freedesktop.org/cairo/cairo/-/issues/252, thanks Caolan for
finding that). This seems to be the case for linux and windows
implementations. Due to the API being on double precision this
is an implementation detail, but it has to be taken into
account when using cairo. It is not officially documented what
is a shame - it should be somewhere in the readmes/
documentation at a prominent place.
24.8 means coordinates are limited to +/- 2^23 (usually minus
one) and [0/256 .. 255/256] places after comma. This is
unfortunately not limited to the view coordinates - that
would be acceptable, discrete/pixel areas of that size should
be fine, BUT used with transformations. Thus when having any
coordinates beyond that limit - and with double precision and
transformations we have that here - cairo just 'cuts' the
coordinates to it's min/max 24.8 format. This is not acceptable
for e.g. a cad system, and even leads to problems in something
like an office suite as we see. It implies that using cairo in
a safe way means to basically use linear algebra yourself in
your app and use cairo only without transformations and with
discrete view coordinates (pixels). AND to know about that
limitation in the 1st place ...
Well, cairo works well and that problem happens until now
in one place in writer below page 490. Let's be pragmatic.
Key is to *detect* the situation. Always doing own
transformations is possible, but not nice: I *could* always
transform the polygon to screen coordinates, but that will
kill the PolyPolygon buffering mechanism (in chart we have
PolyPolygons with 80.000 entries :-); These are held in
cairo_path_t form at the original PolyPolygon to not need
to transform them every time, but let Cairo do that. The
idea is that when Cairo impl may use HW on the system to
do that (HW can do that nowadays) while rendering the
PolyPolygon from the object model would have to be
converted just once to Cairo form and used multiple times...
Cairo *should* be fair, document this and allow you to test/
ask if this limit exists in the version you are using, but
it does not. Thus I suppose to detect that situation as
'cheap' as possible and react to it - e.g. in writer when
below page 490. But not only - it might be possibe to
construct draw/impress pages (free definable) that also reach
that limit.
With detecting as cheap as possible I mean: Naturally you
would start to test your geometry to be painted if it is
overlapping or outside that range defined by 24.8, but
that would already involve transforming all geometry by
world and view transformations. I think it should be okay
to just take the target area (starting at 0,0 and having a
size in pixels) and transforming that back to logical world
coordinates. Then this needs to be checked only if view
transformation changes, not object transformation. Usually
view transformation is setup and all/many objects are
painted to it using object transformations. Detection
should then only be needed when view transform changes.
Thus I added a test (see
checkCoordinateLimitWorkaroundNeededForUsedCairo()). This
is esecuted once per office runtime. If it detects that
the problem is there it sets a flag. Depending on this
the view coordinates are then transformed to logic
coordinates and checked if these are completely inside
the coordinate area that ciaro *can* correctly handle.
This has to be done once per CariroSDPR since (currently)
ViewTransformation is not changed (has to be adapted if
this should happen one day). Based on that the single
helpers on the renderer have to be adapted: Simplest
is just to render using ViewCoordinates - and do
transform object geometry using basegfx/our own stuff
that does that correctly (with ease :-).
Done that, checked, works AFAICT. What a bad surprise,
but I can work around it...
Change-Id: Ic33d6ccfe9854af396d0ac9f14c76eb25bb9e4e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180529
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
|
