summaryrefslogtreecommitdiff
path: root/basegfx/source
AgeCommit message (Collapse)Author
2024-07-16CairoSDPR: Direct support for RGBA Gradients (I)Armin Le Grand (Collabora)
Detect where created when a RGBA gradient could be used directly and create a primitive representing that, a PolyPolygonRGBAGradientPrimitive2D. That primitive decomposes to what was created before, so no primitive renderer has to be touched, all will work as before. NOTE: That helper primitive just holds references to what would be created anyways, so one depth step added but not really any additional data. This is the 1st step for direct support, the 2nd is to then detect and use that primitive in SDPR implementations directly. Change-Id: I4f247636ce58a8a1fd1e0df32dabed0d6cc10d0e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170527 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2024-07-12Make SystemDependentData mechanism type-basedArmin Le Grand (allotropia)
Up to now that genereal buffering mechanism used typeid.*hash_code to identify the class. As we have learned this is not safe. Thus I changed it to use enum'ed SystemDependentDataType definitions Change-Id: I803912ec419290db1d40bae0bc41364fad64cbfd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170385 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2024-07-11CairoSDPR: Improve BColorModified BitmapsArmin Le Grand (allotropia)
There is the complete BColorModifierStack support for primitives for Bitmaps, e.g. hue/saturation, etc, but it was slow due to not being buffered, so had to be re-created often. I changed this to use the common buffering mechanism to improve this. Up to now a fallback to use the old Graphic manipulators for that purpose was in place since this was faster, but had to be done every time. I have now changed the priority to using the primitive way to handle things, but kept the fallback code - just in case. Note that the new stuff is faster, but even much faster when the bitmap is copied and appears multiple times -> the same buffered instance is used, and SDPRs then use the system-dependent data buffered at that prepared data. Also note that this change does not only speedup CairoSDPR, but all PrimitiveRenderers, including the VCL and Metafile ones. In principle everything that uses BitmapEx::ModifyBitmapEx. Had a 2nd thought: Only the content Bitmap gets changed, so for this case we do not need AssociatedAlpha and watch for it to not have changed. Removed that. Change-Id: I2ee36cc84bdc1c723aa01f872edbfd1f51e11c2d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170305 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2024-07-10tsan: ImplB3DPolygon cannot have mutable stateNoel Grandin
because it lives inside a cow_wrapper, which means multiple threads will see inconsistent state. WARNING: ThreadSanitizer: data race (pid=1448100) Read of size 1 at 0x7218002d5a48 by thread T333: 0 ImplB3DPolygon::getNormal() basegfx/source/polygon/b3dpolygon.cxx:998 (libbasegfxlo.so+0xef47a) 1 basegfx::B3DPolygon::getNormal() const basegfx/source/polygon/b3dpolygon.cxx:1477 (libbasegfxlo.so+0xe1834) 2 drawinglayer::processor3d::DefaultProcessor3D::impRenderPolyPolygonMaterialPrimitive3D(drawinglayer::primitive3d::PolyPolygonMaterialPrimitive3D const&) const drawinglayer/source/processor3d/defaultprocessor3d.cxx:424 (libdrawinglayerlo.so+0x1ed388) 3 drawinglayer::processor3d::DefaultProcessor3D::processBasePrimitive3D(drawinglayer::primitive3d::BasePrimitive3D const&) drawinglayer/source/processor3d/defaultprocessor3d.cxx:531 (libdrawinglayerlo.so+0x1edb6f) 4 drawinglayer::processor3d::BaseProcessor3D::process(drawinglayer::primitive3d::Primitive3DContainer const&) drawinglayer/source/processor3d/baseprocessor3d.cxx:57 (libdrawinglayerlo.so+0x1e91c1) 5 drawinglayer::processor3d::DefaultProcessor3D::processBasePrimitive3D(drawinglayer::primitive3d::BasePrimitive3D const&) drawinglayer/source/processor3d/defaultprocessor3d.cxx:543 (libdrawinglayerlo.so+0x1edbe4) 6 drawinglayer::processor3d::BaseProcessor3D::process(drawinglayer::primitive3d::Primitive3DContainer const&) drawinglayer/source/processor3d/baseprocessor3d.cxx:57 (libdrawinglayerlo.so+0x1e91c1) 7 drawinglayer::primitive2d::ScenePrimitive2D::create2DDecomposition(drawinglayer::geometry::ViewInformation2D const&) const::Executor::doWork() drawinglayer/source/primitive2d/sceneprimitive2d.cxx:462 (libdrawinglayerlo.so+0x12469f) 8 comphelper::ThreadTask::exec() comphelper/source/misc/threadpool.cxx:319 (libcomphelper.so+0x2bd587) 9 comphelper::ThreadPool::ThreadWorker::execute() comphelper/source/misc/threadpool.cxx:85 (libcomphelper.so+0x2c3930) 10 salhelper::Thread::run() salhelper/source/thread.cxx:39 (libuno_salhelpergcc3.so.3+0x5d22) 11 non-virtual thunk to salhelper::Thread::run() salhelper/source/thread.cxx:? (libuno_salhelpergcc3.so.3+0x5ed9) 12 threadFunc include/osl/thread.hxx:189 (libuno_salhelpergcc3.so.3+0x6b1e) 13 osl_thread_start_Impl(void*) sal/osl/unx/thread.cxx:237 (libuno_sal.so.3+0xfc937) Previous write of size 8 at 0x7218002d5a48 by thread T334: 0 operator new(unsigned long) /home/noel/llvm-project/compiler-rt/lib/tsan/rtl/tsan_new_delete.cpp:64 (discriminator 8) (cppunittester+0x10c8a1) 1 o3tl::cow_wrapper<ImplB3DPolygon, o3tl::ThreadSafeRefCountingPolicy>::make_unique() include/o3tl/cow_wrapper.hxx:304 (libbasegfxlo.so+0xfe798) 2 o3tl::cow_wrapper<ImplB3DPolygon, o3tl::ThreadSafeRefCountingPolicy>::operator->() include/o3tl/cow_wrapper.hxx:329 (libbasegfxlo.so+0xef0e5) 3 basegfx::B3DPolygon::getNormal() const basegfx/source/polygon/b3dpolygon.cxx:1477 (libbasegfxlo.so+0xe1825) 4 drawinglayer::processor3d::DefaultProcessor3D::impRenderPolyPolygonMaterialPrimitive3D(drawinglayer::primitive3d::PolyPolygonMaterialPrimitive3D const&) const drawinglayer/source/processor3d/defaultprocessor3d.cxx:424 (libdrawinglayerlo.so+0x1ed388) 5 drawinglayer::processor3d::DefaultProcessor3D::processBasePrimitive3D(drawinglayer::primitive3d::BasePrimitive3D const&) drawinglayer/source/processor3d/defaultprocessor3d.cxx:531 (libdrawinglayerlo.so+0x1edb6f) 6 drawinglayer::processor3d::BaseProcessor3D::process(drawinglayer::primitive3d::Primitive3DContainer const&) drawinglayer/source/processor3d/baseprocessor3d.cxx:57 (libdrawinglayerlo.so+0x1e91c1) 7 drawinglayer::processor3d::DefaultProcessor3D::processBasePrimitive3D(drawinglayer::primitive3d::BasePrimitive3D const&) drawinglayer/source/processor3d/defaultprocessor3d.cxx:543 (libdrawinglayerlo.so+0x1edbe4) 8 drawinglayer::processor3d::BaseProcessor3D::process(drawinglayer::primitive3d::Primitive3DContainer const&) drawinglayer/source/processor3d/baseprocessor3d.cxx:57 (libdrawinglayerlo.so+0x1e91c1) 9 drawinglayer::primitive2d::ScenePrimitive2D::create2DDecomposition(drawinglayer::geometry::ViewInformation2D const&) const::Executor::doWork() drawinglayer/source/primitive2d/sceneprimitive2d.cxx:462 (libdrawinglayerlo.so+0x12469f) 10 comphelper::ThreadTask::exec() comphelper/source/misc/threadpool.cxx:319 (libcomphelper.so+0x2bd587) 11 comphelper::ThreadPool::ThreadWorker::execute() comphelper/source/misc/threadpool.cxx:85 (libcomphelper.so+0x2c3930) 12 salhelper::Thread::run() salhelper/source/thread.cxx:39 (libuno_salhelpergcc3.so.3+0x5d22) 13 non-virtual thunk to salhelper::Thread::run() salhelper/source/thread.cxx:? (libuno_salhelpergcc3.so.3+0x5ed9) 14 threadFunc include/osl/thread.hxx:189 (libuno_salhelpergcc3.so.3+0x6b1e) 15 osl_thread_start_Impl(void*) sal/osl/unx/thread.cxx:237 (libuno_sal.so.3+0xfc937) Change-Id: I9a12e2178cfad07f0a23b5dc4c502ce16ef92fb1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170275 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2024-07-09cid#1554691 COPY_INSTEAD_OF_MOVECaolán McNamara
Change-Id: I49597d2f1dc09e843951d10618aa75f702dc70eb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170190 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-07-02SDPRCairo: enhance CairoPixelProcessor2DArmin Le Grand (Collabora)
Added and corrected quite some stuff to this basic construct provided by Caolan (thanks again!). No detailed descriptions here, but it's getting more complete and faster. May contain errors and is primitive-complete in the sense that all gets rendered, but some basic stuff that should be directly supported is still missing, e.g. text rendering. Adding this to allow people to check it out (speed) also since it's not yet used as default in master, so it's safe and also safes the changes publically. To test it, use TEST_SYSTEM_PRIMITIVE_RENDERER as set EnvVar in linux systems. Change-Id: I25f795c9ea4ad4f3b99591304f8803dffa499436 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168911 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2024-06-13Related: tdf#147906 Rename fQuadDist to pointDistanceHakimOttey
after commit 9dad7c0f1095e85ad40ad874215f1051137b0347 Author: HakimOttey <hakimotteybusiness@gmail.com> Date: Mon May 6 12:44:29 2024 -0400 tdf#147906 implement hypot function for s1 x s1 + s2 x s2 statements where the names were kept, but became confusing. Change-Id: If2bfa4b5fc1dd04bb4f1026b6f89e3c97a43caf8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167850 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-05-20tdf#147906 implement hypot function for s1 x s1 + s2 x s2 statementsHakimOttey
Change-Id: I50a2f4cf7738ee3797723929fb6840d2633c882c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166814 Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Tested-by: Jenkins Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2024-05-07loplugin:ostr basegfxNoel Grandin
Change-Id: I79212cbfd1c7cae810f8e24dbd73372b9f97f9ef Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167190 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-05-02cid#1596705 Unused valueCaolán McNamara
Change-Id: Ie5bfe55fd964c05f80d3400a66aa79886f3c144b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166983 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Jenkins
2024-04-29Drop uses of css::uno::Sequence::getConstArray in accessibility .. basegfxMike Kaganski
where it was obsoleted by commits 2484de6728bd11bb7949003d112f1ece2223c7a1 (Remove non-const Sequence::begin()/end() in internal code, 2021-10-15) and fb3c04bd1930eedacd406874e1a285d62bbf27d9 (Drop non-const Sequence::operator[] in internal code 2021-11-05). Change-Id: I14e3634d8e8dd294b673dcda4dde13f01c3e5112 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166813 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2024-04-19loplugin:constantparamNoel Grandin
Change-Id: I58e31ffdfc87a15e82bce54afd47ff3906159707 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166293 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-04-15Generalize basegfx::fround for templated return typeMike Kaganski
And use it when assigning to tools::Long Change-Id: I0814d7bac9cdd48191ba69c64e3b12a4973b3417 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166071 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-04-05tdf#147906 Use std::hypot for Pythagorean distanceRMZeroFour
As part of the efforts in tdf#147906 to replace expressions like sqrt(a^2 + b^2) with std::hypot(a, b), to eliminate overflow errors, this commit performs the changes in certain files. This also changes the B3DVector::normalize and B2DVector::normalize methods to have similar behaviour. Change-Id: I142585cfa594849f06cd06517ad9d40430df2ade Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165555 Tested-by: Hossein <hossein@libreoffice.org> Reviewed-by: Hossein <hossein@libreoffice.org>
2024-03-26tdf#159805 Printing line style dotted lines (horizontal) turns into dashes.Noel Grandin
I could not find a good place to distinguish between the dragging visualisation (where we could safely use approximation), and the non-dragging case, so just revert. Revert commit 9f4ccc63346b26d8d774b22124da0842ef18e0bc Author: Noel Grandin <noel.grandin@collabora.co.uk> Date: Wed Sep 13 14:27:02 2023 +0200 tdf#156995 speed up dragging complex group objects Change-Id: I2ba52f07ea7299643c0f145459038e368a17dea8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165332 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-03-26tdf#160084 Simplify comparison for basegfx::fToolsBogdan Buzea
Change-Id: If1a2d000e7059856280bd1acb959b35c412777df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165184 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-03-23tdf#157664 Drop redundant operator != in basegfx moduleRMZeroFour
As part of the efforts in #157664 to remove redundant definitions of operator!=, to upgrade the codebase to C++20, this commit removes the remaining definitions in the basegfx module. Change-Id: I19f2b9ddf42185435313445c8395a851030e2149 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165199 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2024-03-21Fix typoAndrea Gelmini
Change-Id: Ib12a2b2f76f3819a3c0355f45ef56d3e861530a6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164545 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2024-03-10basegfx : use OUstring literal for XServiceInfo implementationArnaud VERSINI
Change-Id: I18a17e38897c1feda7fbba330c14a79c9b6d6f93 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164306 Tested-by: Jenkins Reviewed-by: Arnaud Versini <arnaud.versini@pm.me>
2024-03-07Simplify some basegfx::fTools::*orEqual callsNoel Grandin
Comparing with zero is simple - the implementation of basegfx::fTools::moreOrEqual calls rtl_math_approxEqual eventually, which special-zases zero. Change-Id: I62f10f63f103d91a201dfeb20e5b3f9010f377c1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164526 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-01-21tdf#157664 Drop operator != where respective == is definedAkshayWarrier
Change-Id: I9eb0ea94f10126270f6e7c4433227ea60c21db79 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162336 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-11-03tdf#157664 Drop operator !=, where respective operator == is definedAnkit_Jaipuriar
Change-Id: I88b25dd676fc57303978e3d5e875af129240b676 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157762 Tested-by: Jenkins Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2023-10-08Drop temporary aliases from Tuple2D and Tuple3DMike Kaganski
Change-Id: I091b68bbeee74452a3d6a03711cfc482b7a78e1d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157685 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-09-28cid#1545233 sidestep COPY_INSTEAD_OF_MOVECaolán McNamara
Change-Id: I93b8225b7ae2fdb4ea5fc371ce278f00d3dec33f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157356 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-09-13tdf#156995 speed up dragging complex group objectsNoel Grandin
These shaves 20% of the time of the construction of the "drag view" object. Of course, it is still heinously slow. Change-Id: I4c6ee2d7e0cc2030a9966a281d2fdbe7f6859289 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156896 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-08-24tdf#112687 Simplify polylines from slideshow annotationsRegina Henschel
Drawing with 'mouse as pen' in a slideshow creates hundreds of points. By commit 631964a2ce1da3fbbeb53a5550c0e6728ba644aa they are at least already combines to a polyline. The patch here now reduces the amount of points in such polyline to a reasonable number. If at some point the drawings in the slideshow are improved, this can be removed. The reduction is performed using the Douglas-Peucker algorithm. I have added the method to b2dpolygontools because I think it could be useful in other contexts. Change-Id: I9224ec3546d4442da8bc348aea8ce7b88fcc46dc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155811 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-08-21move BGradient to awt::Gradient2 UNO conversion into docmodelTomaž Vajngerl
This is needed because the module dependencies are an issues if the conversion is done in basegfx. The bigger issue will come when the ComplexColor conversion will be done as basegfx can't depend on docmodel because of circular dependencies. The BGradient is also more suitable for docmodel anyway as the previously it was part of the model and is not a basic (gfx) type - however this doesn't move the whole BGradient into docmodel yet. Change-Id: Id91ce52232f89f00e09b451c13da36e2854ae14b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155674 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-07-31loplugin:constantparamNoel Grandin
Change-Id: Iac66822757814d67383f6e19f3ab25e3dc7f8b0f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155085 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-07-23ofz#57493 TimeoutCaolán McNamara
Change-Id: Id8811e65227142881fc86f6d2db231fa053fc2d3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154768 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-07-21loplugin:redundantcast small improvementNoel Grandin
Change-Id: I2c96b367138b94d6178a3c4a0f83049f13a04f82 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154679 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-07-13basegfx: replace typedef with a class B2ISize based on Size2DTomaž Vajngerl
Change-Id: Iaf7d02bb236f81a38a67a1430a718b6c3c78efae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139708 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-07-10tdf#99562: Do not ignore last column from matrixXisco Fauli
Change-Id: I1dff65963e2c414d1771a1592159930150c513e0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154241 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-07-07related: tdf#155735: clamp RGB valuesXisco Fauli
So when a green matrix is used, everything becomes green. Also set alpha to 1.0 so at least a green matrix on black returns green and not black Change-Id: I9104c7511545fb244750b066bb1e996b6ce229f2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154167 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-07-04loplugin:constantparamNoel Grandin
Change-Id: Iee554baae7239c9bf0ac35cab6ff235a88dc29a1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153973 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-06-26Revert "tdf#132246, tdf#155735: Add support for SourceAlpha"Xisco Fauli
This reverts commit 75399b8aad6c0f0998b9d0a6eddb2e29f8bc114c. it was incomplete. While at it, do not parse 'in' attribute for now, so only in="SourceGraphic" is used. Implementing the 'in' attribute is not trivial Change-Id: I66c721c1144638f5e3759e0aa3a1c2c062499a90 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153627 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-06-25tdf#155735: use 4x4 matrices in testsXisco Fauli
Change-Id: I7258443036eb89e7a67fce2a683f3212972a7395 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153565 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-06-24tdf#132246, tdf#155735: Add support for SourceAlphaXisco Fauli
Change-Id: I8feae2447b17e15113ca45fe46c0d68cb6b6ab71 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153550 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-06-22tdf#155735: Add support for matrix typeXisco Fauli
Change-Id: Icc172c5f47731ddcf0beca64c72c2022313e74a7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153177 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-06-22tdf#155735: Add support for hueRotate typeXisco Fauli
Change-Id: I9c7ada2908c0739708fbc9e28ac58430350da7a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153112 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-06-21tdf#155735: use B3DHomMatrix in BColorModifier_saturateXisco Fauli
Change-Id: Ibdbe9c55220239f4b8458742ac5625c002963217 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153390 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-06-16tdf#155852 same method for StepCount in OOXML as in renderingRegina Henschel
Rendering of stepped gradients uses a method that doesn't take the color from a cut point, but before or after respectively. For example, for StepCount 4, the colors at relative positions 0, 1/3, 2/3 and 1 are used. So sections are 'start color', '1/3 color', '2/3 color' and 'end color'. The output to OOXML now uses the same method. That way rendering in a produced pptx-file is the same as in the original odp-file. Since OOXML has nothing similar to StepCount, it is an export only problem. A second problem comes from the cuddle with StepCount in Gradient struct in API and FillStepCount in shape property set. The draw:gradient-stop-count attribute in ODF belongs to the graphic style of the shape. The gradient definition itself in the <draw:gradient> element has nothing about step count. When a file is opened, it can be that the StepCount component in the Gradient struct still has the default value 0, but the FillStepCount property has the correct value of the shape. The Gradient struct in the API should not have a component StepCount to be compatible with ODF. But the API is published and changing that struct is far-reaching in the code. So the fix here is not a general solution but solves the problem for export to OOXML by reading the FillStepCount property while exporting. Change-Id: Ie1cafe6bdda7c4d74b05f279f0d8212ff67ecc92 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153154 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-06-14tdf155825 result same size in synchronize gradientsRegina Henschel
While synchronizing color and transparency gradients two new sequences are generated. In case the last offsets where different, the remaining stops where not copied to the new sequence and thus they had different sizes which triggered an assert in oox/source/export/drawingml.cxx. Change-Id: I446f8cfafb23735f06ad4e05eee8c922141b864d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153063 Tested-by: Jenkins Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-06-14tdf#155735: Add support for saturate typeXisco Fauli
Add getModifierName to BColorModifier class so when can assert which modifier is being used Change-Id: I2bc2a36470a449df4dc84a8440f232149c1f8278 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153048 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-06-13tdf#145538 Refactor to use range-based for-loopbuldi
Change-Id: I7c75593fef6d3226011a938349850dc485b763c2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148204 Tested-by: Jenkins Reviewed-by: Hossein <hossein@libreoffice.org>
2023-06-09Fix typoAndrea Gelmini
Change-Id: Iaebe55927771985a6b574b2cb9410b0eb75441e1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152789 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-06-09Fix typoAndrea Gelmini
Change-Id: Ib02cc0e9aaf286d8c39523ea352cfeec17a6336f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152788 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-06-09MCGR: tdf#155479 repair gradient SVG export for MCGRArmin Le Grand (allotropia)
Unfortunately SVG export is based on metafiles and thus there is (in principle) no way to get the BGradient/ColorStop/MCGR data transfered as needed. For that, using UNO API to read the model or using B2DPrimitives would help - as is better for the export respectively. Since there is not the time to re-design SVG export I added this 'compromize' as a fix. It gets the needed data transported over the metafile (that part is the compromize). It then exports the MCGR data to SVG (at least - as was already there - if it's a linear/axial gradient). This happens now with all Gradient Stops when there is a MCGR gradient. That part is/will hopefully be re-usable if SVG export gets redesigned. I also added a handling for StepCount feature, so when used (in LO, others do not have that) 'hard' color stops get generated to make the gradient look identical for SVG export. Had to make adding of that extra-information in metafiles dependent on exporting really to SVG. There are 51 cases which use 'MetaActionType::COMMENT' which would potentially have to be adapted. Also added code to solve the problem for TransparencePrimitive2D at VclMetafileProcessor2D::processTransparencePrimitive2D. This will now - also only for SVG export - directly create the needed MetaFloatTransparentAction and add additional MCGR information. This will be used on SVG export to write a 'Mask' as was done before. This is now capable of creating fill MCGR-Masks in the sense that any number of TransparencyStops will be supported. Change-Id: Ic6d022714eae96b8fbc09e60652851ac5799b757 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152623 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-06-06MCGR: tdf#155537 correct usage of wrong result in toolingArmin Le Grand (allotropia)
Change-Id: I8f68ecc7ccaecf84abbcda1bcdd65e2295baaf0f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152673 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de> Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-06-05tdf#155549 MCGR: Recreate 'axial' from symmetric 'linear'Regina Henschel
When exporting a shape with an axial gradient fill to OOXML, it is converted to a linear gradient with multiple color stops. Versions before MCGR had recreated it as axial gradient on import from OOXML. But now LO is able to handle multiple color stops and so the linear gradient from OOXML is imported as linear gradient in LO. When such file is then written as ODF, the multiple color stops are in elements in extended namespace and versions before MCGR do not understand them. They show only the first and last color (which are equal) and the gradient is lost. With this patch LO converts the linear gradient back to an axial gradient on export to ODF. The exported axial gradient is rendered in a version with MCGR same as the linear gradient when opening the OOXML file. The difference is, that versions without MCGR now render an axial gradient with two colors. Change-Id: I2b416b4cdca75d8327107a4f259d63c2e6e97ac3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152574 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-05-28Use getXWeak in basegfxMike Kaganski
Change-Id: I650a8fcefd179937bdcbb6088658aa960008794d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150834 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
generated by cgit (git 2.34.1) at 2024-12-26 09:33:56 +0000