summaryrefslogtreecommitdiff
path: root/sal/util
ModeNameSize
-rw-r--r--sal.map22191logplain
generated by cgit (git 2.34.1) at 2025-01-04 06:12:01 +0000
'> To more directly support an additional alpha channel for BitmapPrimitive data I have done some deeper changes to the primitive stack, in a compatible way. Quite some more graphic types and primitives now support an additional direct alpha value. All that is decomposed/created/broken down in a way that needs no changes for existing renderers, in already described ways. The CairoPixelProcessor2D already uses this in the processFillGraphicPrimitive2D implementation and thus in the FillGraphicPrimitive2D. This works since primitive productions now all try to create that FillGraphicPrimitive2D type including an additional alpha value - if possible and necessary. Change-Id: Ib1b16491a2b3aee16f14cc8196e28af30a7cf9be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170900 Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com> Tested-by: Jenkins 2024-07-18Fix typoAndrea Gelmini Change-Id: Iedb3495fe6cdbcdea9f6a60c004b518665ef4b76 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170375 Tested-by: Jenkins Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net> 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-10CairoSDPR: Handle FillGraphicPrimitive2D betterArmin Le Grand (allotropia) Avoid decomposition of it in AnimatedExtractingProcessor2D by handling there directly. Goal is to find/extract animation primitives, so only do something when the contained Graphic is active Change-Id: I1d168428ddbaaac2c9d5fde7b26be380ba442c30 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170203 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com> 2024-02-12make BufferedDecompositionPrimitive2D store a Primitive2DReference..Noel Grandin .. instead of a Primitive2DContainer. The container very frequently contains only a single item, since the decomposition method often sticks only a single top-level node in there, so it turns out to be a net loss overall, memory consumption-wise. Also, if we return a single Primitive2DReference from a BufferedDecomposition, that maximises the sharing of data between the BufferedDecomposition objects at the bottom of the decomposed tree, and objects higher up. Change-Id: Iaf272e60e2997299cc35a1bd209c51b6b79e9a8b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162976 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2024-02-07these casts are no longer necessaryNoel Grandin Change-Id: Ife51f47d95e286e0fec165882377c31b1a664241 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163058 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2023-12-19Add flush mechanism to buffered PrimitivesArmin Le Grand (allotropia) There are the classes BufferedDecompositionPrimitive2D and BufferedDecompositionGroupPrimitive2D that offer a unified mechanism to preserve/buffer the decomposition of a Primitive, independent of the complexity. This may include e.g. the pixel representation of a 3D Scene, for Charts/CustomShapes and others. Until now these were refreshed when the objects change, or when the buffered decomposition decides that it is necessary, but there was no general mechanism in place to clean these up while the Primitive owning them was alive/used. This is not a big thing in Draw/Impress since this would only be relevant when zooming deep into a SdrPage, so the non-vislible parts would still hold data that would not be needed. But for Calc and Writer this is more relevant: A 3D Chart on the 1st page of a Writer document would be held buffered all the time a user would work on pages below that. This is good for guaranteeing fast re-visualization when scrolling up again, but until then would just block memory. So I added this general mechanism that allows activating flushing timer-based, on Seconds. The default is null seconds, thus deactivated. It should only be used for Primitives that can get expensive, not for all. NOTE: I checked activating for all Primitives to be on the safe side, works. It is now (initially) activated for: - GlowPrimitive2D - GraphicPrimitive2D - MetafilePrimitive2D - ScenePrimitive2D - ShadowPrimitive2D (softShadow) - SoftEdgePrimitive2D - SdrCustomShapePrimitive2D - SdrGrafPrimitive2D These are the usual suspects that may use some memory to buffer their decomposition (for good reasons, each repaint uses it). Other Primitives which may show need to be treated this way can easily be added, just by calling setCallbackSeconds(s) in their constructor. This is true for all Primitives derived from the two classes mentioned above. NOTE: Too short buffering times are *not* useful - e.g. for a expensive-to-be-recreated 3D chart representation this may not pay out, so I chose times in a way that try to respect this. NOTE: This change needs 7397fa7cdfc33f5a079df42e4d6cfa59ae9e062d to work correctly (thanks to sberg for this). Without this the office hangs/does not terminate regularly in trying to destroy the 'TimerManager'. Change-Id: Id4802afcb6d12480bb2935cc1ef67fe443b3b788 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160926 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com> 2023-12-16cid#1545970 COPY_INSTEAD_OF_MOVECaolán McNamara and cid#1545957 COPY_INSTEAD_OF_MOVE cid#1545944 COPY_INSTEAD_OF_MOVE cid#1545939 COPY_INSTEAD_OF_MOVE cid#1545931 COPY_INSTEAD_OF_MOVE cid#1545926 COPY_INSTEAD_OF_MOVE cid#1545909 COPY_INSTEAD_OF_MOVE cid#1545899 COPY_INSTEAD_OF_MOVE cid#1545896 COPY_INSTEAD_OF_MOVE cid#1545894 COPY_INSTEAD_OF_MOVE cid#1545858 COPY_INSTEAD_OF_MOVE cid#1545823 COPY_INSTEAD_OF_MOVE cid#1545820 COPY_INSTEAD_OF_MOVE cid#1545819 COPY_INSTEAD_OF_MOVE cid#1545772 COPY_INSTEAD_OF_MOVE cid#1545749 COPY_INSTEAD_OF_MOVE cid#1545743 COPY_INSTEAD_OF_MOVE cid#1545739 COPY_INSTEAD_OF_MOVE cid#1545635 COPY_INSTEAD_OF_MOVE cid#1545603 COPY_INSTEAD_OF_MOVE cid#1545602 COPY_INSTEAD_OF_MOVE cid#1545592 COPY_INSTEAD_OF_MOVE cid#1545544 COPY_INSTEAD_OF_MOVE cid#1545532 COPY_INSTEAD_OF_MOVE cid#1545520 COPY_INSTEAD_OF_MOVE cid#1545512 COPY_INSTEAD_OF_MOVE cid#1545490 COPY_INSTEAD_OF_MOVE cid#1545483 COPY_INSTEAD_OF_MOVE cid#1545467 COPY_INSTEAD_OF_MOVE cid#1545461 COPY_INSTEAD_OF_MOVE cid#1545458 COPY_INSTEAD_OF_MOVE cid#1545428 COPY_INSTEAD_OF_MOVE cid#1545394 COPY_INSTEAD_OF_MOVE cid#1545385 COPY_INSTEAD_OF_MOVE cid#1545383 COPY_INSTEAD_OF_MOVE cid#1545366 COPY_INSTEAD_OF_MOVE cid#1545357 COPY_INSTEAD_OF_MOVE Change-Id: I76224326977b4067b94ca3176cad1ca6de17930a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160847 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> 2023-12-14cid#1545734 COPY_INSTEAD_OF_MOVECaolán McNamara and cid#1545723 COPY_INSTEAD_OF_MOVE cid#1545708 COPY_INSTEAD_OF_MOVE cid#1545705 COPY_INSTEAD_OF_MOVE cid#1545684 COPY_INSTEAD_OF_MOVE cid#1545674 COPY_INSTEAD_OF_MOVE cid#1545673 COPY_INSTEAD_OF_MOVE cid#1545667 COPY_INSTEAD_OF_MOVE cid#1545661 COPY_INSTEAD_OF_MOVE cid#1545660 COPY_INSTEAD_OF_MOVE cid#1545657 COPY_INSTEAD_OF_MOVE cid#1545653 COPY_INSTEAD_OF_MOVE cid#1545636 COPY_INSTEAD_OF_MOVE cid#1545624 COPY_INSTEAD_OF_MOVE cid#1546124 COPY_INSTEAD_OF_MOVE Change-Id: I7d50594e046a022147d9ddf077b8b2d8027f9bca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160721 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> 2022-06-15clang-tidy modernize-pass-by-value in drawinglayerNoel Grandin Change-Id: I8a3245c6a4d687edbc95cf28b2932d80c86a7b65 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135828 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2022-05-30use more Primitive2DContainer::append and more std::moveNoel Grandin Change-Id: Ide40a08f70cbb30a4f18c496d986feb78e5dfa1c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135103 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2021-09-24reduce copying in drawinglayerNoel Grandin by passing PrimitiveContainer&& around. There are lots of place where we were preparing a local variable of type PrimitiveContainer, and then copying it someplace else, then throwing it away. Change-Id: Iacfd983640c9e55da25800ccc01734dfc8b4d64a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122527 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2021-09-09tdf#144052 reduce Primitive2D copyingNoel Grandin when creating charts, by using a Primitive2DContainer&& parameter in the GroupPrimitive2D constructor, which forces the call sites to pass a temporary, and at most call sites, we can std::move in an existing local variable. Change-Id: I531970918800c6832ab606b5a4ff5fd2d47ccf5b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121844 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2021-08-31clang-tidy:readability-redundant-member-initNoel Grandin Change-Id: I95918275653714577e2d6728dd3947c7fbb66d8f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121360 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>