Age	Commit message (Collapse)	Author
2024-10-21	vcl: move bitmap filter headers into vcl/bitmap global header directory	Chris Sherlock
	Use #pragma once instead of header guards Change-Id: Iba43f2103628ed184933cf2611991e7aef9f0173 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173369 Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Tested-by: Jenkins
2023-12-06	make AlphaMask separate from Bitmap	Noel Grandin
	Having it subclass Bitmap encourages confusion in passing it around, and I need the extra type-safety for my work on merged-alpha Change-Id: I35819f9b8ee609cbdaf865563c78531e397b529b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160235 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-12-03	ProcessAndBlurAlphaMask should take an AlphaMask as param	Noel Grandin
	Change-Id: I9235e74499d95750ca93da050014657b418c27d1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160249 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-11-05	tdf#158014 Skia adds filled white areas in .svg when exporting to PDF	Noel Grandin
	So my strategy here is to assume that ProcessAndBlurAlphaMask was doing the right thing before commit 81994cb2b8b32453a92bcb011830fcb884f22ff3 Date: Fri Apr 16 20:33:10 2021 +0200 Convert internal vcl bitmap formats transparency->alpha (II) but the subsequent naiving changing of its logic undermines it because of some subtle interaction. So take the brute force approach of reverting most of the code to its prior state (i.e. working in the transparency domain), and doing an Invert() before and after the original code. This seems to fix all of the test files I have on hand for this situation for both Skia and non-Skia cases. Change-Id: If4c4d4c5351a4ec55897bed96b57d28eda88f5dd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158793 Tested-by: Jenkins Reviewed-by: Patrick Luby <plubius@neooffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-08-17	Simplify a bit	Mike Kaganski
	Change-Id: I4cc8f6dbaec0edd8a7a761f03868035350e01734 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155760 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-08-05	Related tdf#156508 fix rendering of the About dialog .svg	Patrick Luby
	After 0e7d4ea64f84bdc62c10692dcd97c3a32e72e16e, white polygons are drawn in the LibreOffice about .svg in both the About dialog and with the .svg in a document. Creating the mask with COL_WHITE instead of COL_BLACK appears to fix this without causing tdf#156508 to reoccur. Change-Id: I886451245126c2b7f936e30275965148bf029627 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155362 Tested-by: Jenkins Reviewed-by: Patrick Luby <plubius@neooffice.org>
2023-08-04	tdf#156508 Blur shadow is solid in edit and presentation mode	Noel Grandin
	regression from commit 81994cb2b8b32453a92bcb011830fcb884f22ff3 Author: Noel Grandin <noelgrandin@gmail.com> Date: Fri Apr 16 20:33:10 2021 +0200 Convert internal vcl bitmap formats transparency->alpha (II) Change-Id: I14f62547e3301cab0eff79716bf7bc2a51ead563 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155338 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-07-25	Convert internal vcl bitmap formats transparency->alpha (II)	Noel Grandin
	(Second attempt at landing this) Image formats and graphics APIs use alpha, not transparency, so change our internal formats and data structures to work directly with alpha, so we don't need to modify data before we push it to graphics APIs. Add a couple of new Color constants to make the intention of the vcl code clearer. Notes () On macOS, tweaking the logic in CreateWithSalBitmapAndMask to more accurately reflect the requirements of the CGImageCreateWithMask function seems to fix some tests. () The vcl code does not properly support gradients with transparency. So the previous code was wrong, and this change is going to result in slightly different wrongness. Change-Id: I9e21c2e98d88ecfdc5f75db13bd1ffff7c38db98 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114168 Tested-by: Jenkins Reviewed-by: Patrick Luby <plubius@neooffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-11-08	Update handling of AntiAliasing settings and processor2d	Armin Le Grand (allotropia)
	Currently SvtOptionsDrawinglayer::IsAntiAliasing() is used in the constructor of the VCL based processor2Ds to decide if AA is to be used or not. Using this inside the constructors makes it currently impossible to use a primitive renderer independent from these settings, except when changing these settings temporarily what may influence other renderings and is a hack. The setting SvtOptionsDrawinglayer::IsAntiAliasing() is intended to decide if LO shall use AA mode from user's perspective, this means for the EditViews of the Apps and some other occasions (previews, exports, conversions to bitmap, ...). This works currently since all visualizations for these purposes use newly constructed primitive renderers. But there is no way to use primitive renderers independent from that setting. For future renderers which might be used for other purposes this is not sufficient, there has to be a method to create a renderer using e.g. AA independent of the global setting. To allow that, move the deciding flag to the already used geometry::ViewInformation2D. To not change anything initially, use the global flag for now to init that default value at ViewInformation2D. I took the opportunity to adapt ViewInformation2D to no longer being read-only and not changeable, it uses internally an impl class based on cow_wrapper already anyways. Extending this would lead to the constructors getting even bigger, when usually only 1-3 values need to be changed and many usages want to copy an existing instance and modify it. Adapted that usages to a much smaller footprint. Up to this point this does not change anything, but move the usage of the SvtOptionsDrawinglayer to the defaults (constructors) of the involved class ViewInformation2D. Using this then in the primitive rederers should be safe and will allow to use a primitive renderer with or without AntiAliasing independent of the user setting, so also for non- EditView usages. Also already added the PixelSnapHairline setting, this will also be needed independent of user settings to have full freedom of usage. Unfortunately I cannot use SvtOptionsDrawinglayer methods ::IsAntiAliasing() or ::IsSnapHorVerLinesToDiscrete inside ViewInformation2D where I would need it. It's now in drawinglayercore and thus not linked against svtools (svt) anymore. Thus I have to do some forwarding mechanisms to get the correct values available in ViewInformation2D. Not nice, caused by creating drawinglayercore... Change-Id: I9f572ce67e5d86a242188bdc6d4ba7c9a12f6a9b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142393 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-09-14	Rework of ShadowPrimitive2D	Armin Le Grand (allotropia)
	This is pretty much the same for ShadowPrimitive2D as the change for GlowPrimitive2D and SoftEdgePrimitive2D, so for more comments please refer to those commits: c2d1458723c66c2fd717a112f89f773226adc841 707b0c328a282d993fa33b618083d20b6c521de6 There are some needed differences due to ShadowPrimitive2D having existed longer and is used for non-blurred shadow for a long time and is used as unchanged as possible. Only for active glow of shadow is a buffering and local decompose used. Change-Id: I55e6516f59390079356ac16f24743b474e53fb05 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139858 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-09-01	explicitly use BmpScaleFlag::NearestNeighbor when wanted	Luboš Luňák
	That is the algorithm that doesn't change colors, BmpScaleFlag::Fast works the same way only because it's mapped to this algorithm (which may not necessarily be the case forever). Change-Id: Ibebfff668eaa1da93963f8e8601fec51cfdfca34 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139128 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-08-31	Rework of GlowPrimitive2D	Armin Le Grand (allotropia)
	The new version does all needed stuff inside the GlowPrimitive2D implementation. Advantages are: - there is no need anymore to handle directly in the renderer implementations. That includes HitTest & future renderers, but also the currently existing fallback from MetafileRenderer to PixelRenderer - the buffered B2Primitive can re-use the last, potentially expensively cerated pixelation result - it checks for the possibility to do so using various aspects (see implementation, more would be possible) - it no longer uses impBufferDevice in the not wanted double-vdev/alpha-channel mode from presentation engine - it offers an example how to do all this with just a primitive (that can be replaced with another impl if needed without having to adapt any renderers). To support that, I added plenty of comments The group of GlowPrimitive2D, SoftEdgePrimitive2D and ShadowPrimitive2D use impBufferDevice in that much slower and expensive mode (two VDevs, processor-based alpha mixing). To get back to faster transparence rendering in general this is a 1st step, we also will need to re-work the other two mentioned primitives. The reworked one is now more efficient. Change-Id: I25c6fb970682b5311ce6f9ca4abf2702fb7c8862 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138973 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>