summaryrefslogtreecommitdiff
path: root/basegfx
AgeCommit message (Collapse)AuthorFilesLines
4 daysloplugin:constantparamNoel Grandin1-24/+3
Change-Id: I58e31ffdfc87a15e82bce54afd47ff3906159707 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166293 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
9 daysGeneralize basegfx::fround for templated return typeMike Kaganski1-12/+12
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 distanceRMZeroFour3-21/+20
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 Grandin1-39/+12
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 Buzea2-5/+5
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 moduleRMZeroFour7-40/+0
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 Gelmini1-1/+1
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 VERSINI1-2/+2
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 Grandin8-19/+18
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-03-06Use less boost_headers in low level librariesGabor Kelemen1-2/+0
Most of these don't use boost themselves, nor do they need it transitively since the use of boost::optional was removed Change-Id: Ic9dee1c4e160b313ec5b91677b02ffdea6c5779d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164440 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-01-21tdf#157664 Drop operator != where respective == is definedAkshayWarrier1-5/+0
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_Jaipuriar2-10/+0
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-19Extended loplugin:ostr: Automatic rewrite O[U]StringLiteral: basegfxStephan Bergmann3-18/+18
Change-Id: If228639806c49d77d1c1a36a8d536992e1402896 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158144 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-08Drop temporary aliases from Tuple2D and Tuple3DMike Kaganski4-49/+49
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 McNamara2-41/+34
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 Grandin1-12/+39
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 Henschel1-0/+100
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ž Vajngerl1-167/+0
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 Grandin1-65/+18
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 McNamara1-1/+1
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 Grandin1-2/+2
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ž Vajngerl1-6/+6
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 Fauli2-49/+79
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 Fauli2-12/+11
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 Grandin1-17/+6
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 Fauli2-46/+0
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 Fauli2-0/+12
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 Fauli2-0/+46
Change-Id: I8feae2447b17e15113ca45fe46c0d68cb6b6ab71 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153550 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-06-22basegfx: Add test for BColorModifier_black_and_whiteXisco Fauli1-0/+27
Change-Id: I35193c68034e5500f12a2e474886c6aa9c2307ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153457 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-06-22tdf#155735: Add support for matrix typeXisco Fauli2-0/+117
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 Fauli2-0/+84
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: Add tests in basegfxXisco Fauli1-0/+66
Add tests for BColorModifier_luminance_to_alpha and BColorModifier_saturate Use basegfx::fTools::equal in B3DTuple::operator==, otherwise some asserts fail with - Expected: [0.3575, 0.8575, 0.3575] - Actual : [0.3575, 0.8575, 0.3575] Although they are equal Change-Id: Iad6d9ff78a390f5ee2a3e33e479e34d98e751b2e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153394 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-06-21tdf#155735: use B3DHomMatrix in BColorModifier_saturateXisco Fauli1-5/+21
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 Henschel1-7/+7
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 Henschel1-0/+2
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 Fauli1-0/+74
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-loopbuldi5-63/+41
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 Gelmini1-1/+1
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 Gelmini1-1/+1
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)1-0/+137
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)1-1/+1
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 Henschel1-1/+52
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 Kaganski1-1/+1
Change-Id: I650a8fcefd179937bdcbb6088658aa960008794d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150834 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-05-26MCGR: Border restoration supportArmin Le Grand (allotropia)2-71/+232
Due to tdf#155362 I added code to be able in case we would need it to convert a BGradient using added tooling from having offsets in the GradientSteps and no border to adapted GradientSteps and border. This is preferrable due to our GradientStyle_RECT (and GradientStyle_ELLIPTICAL too) use that 'non- linear' paint aka move-two-pixels-inside, someone else called it 'frame-paint'. This does not bode well with the border being applied 'linear' at the same time (argh). Thus - while in principle all is correct when re-importing a GradientStyle_RECT with a border after export to pptx, it looks slightly better ('correcter') wen doing so. That is because when being able to and restoring a border at least that border part *is* applied linearly. I took the chance to further apply tooling, move it to classes involved and instead of awt::Gradient2 use more basegfx::BGradient since it can and does host tooling. This is also a preparation to be able to adapt (restore) border in case of turn- around in ODF where the importing instance is before MCGR existance and has to handle Start/EndColor. Needed to take more care with using BGradient instead of awt::Gradient2 for initialization, also better dividing/organization of tooling, already preparation to use for other purposes. Change-Id: I2d3a4240a5ac6fff9211b46642ee80366dc09e3d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152194 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-05-20loplugin:unusedmethodsNoel Grandin3-41/+0
Change-Id: Ief95f111350808f010539bb733a553007d30a9df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152006 Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-05-19MCGR: Adaptions to WriteGradientFill and BGradientArmin Le Grand (allotropia)2-68/+31
Added code to make WriteGradientFill directly use the available BGradient implementation. The goal is to never directly work on awt::Gradient2, but use BGradient & it's tooling methods. Added constructors and tooling to BGradient and BColorStops to make that easier (single line conversions between uno::Any, basesgfx classes and awt:: incarnations). Directly handle uno::Any and awt:: classes, changed stuff to make use of this. Change-Id: I083a323b9efee8ca4f3becb2966aac0a294b9a60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151842 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-05-18improved B2DHomMatrixNoel Grandin4-193/+102
since we know that this is a matrix only used for 2D transforms, we know that the last row of the matrix is always { 0, 0, 1 }. Therefore, we don't need to store that information, and we can simplify some of the computations. Also remove operations like operator+ which are not legal for such a matrix. Change-Id: I482de9a45ebbedf79e3b6033575aab590e61c2d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151909 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-05-17tdf#63130 use a simpler, SIMD-friendly algorithm for matrix invertNoel Grandin1-11/+45
which is 10% faster loading this document Algorithm copied from https://github.com/niswegmann/small-matrix-inverse/blob/master/invert3x3_c.h, which is CC0-1.0 licensed. Change-Id: I7aa272cae90b1aee30eb6b3e8e5acb260b92ceef Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151830 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-05-16Fix typoAndrea Gelmini1-1/+1
Change-Id: Id590b13237bc148dac955d6f4d56092f86d1dd16 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151817 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-05-16Fix typoAndrea Gelmini1-1/+1
Change-Id: I5701a1fdfe9e4f139049ed6c0de1748ec7c06e07 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151816 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-23 22:43:57 +0000