/chart2/

Age	Commit message (Collapse)	Author
2024-10-01	CairoSDPR: Support direct RGBA for convertToBitmapEx	Armin Le Grand (allotropia)
	Added general interfaces to be able to render directly to an RGBA target SDPR: - processor2d::createPixelProcessor2DFromScratch creates a target-SDPR with given pixel size and RGB or RGBA, owning and using a cairo surface internally - processor2d::extractBitmapExFromBaseProcessor2D extracts rendered content to BitmapEx, including alpha All this is currently only implemented for Ciaro, thus the internal impls are encapsulated by USE_HEADLESS_CODE, but already created gererally available. The return values have to be checked to see if an evtl. shortcut is possible. For convertToBitmapEx this means that it can do conversions much faster than up to now for cairo when CairoSDPR is available, else it has to to the older slower way that also works and is the default: Create RGB content, create Mask, RemoveBlendedStartColor (see convertToBitmapEx implementation). This works and has the same quality, but needs two renderings and one bitmap operation, thus is clearly slower. Note that these interfaces can and will be supported for other SDPR implementations in the future, thus will make this converter automatically faster on systems where we will have a SDPR in the future, too. Also note that this is the gereral converter from a sequence of Primitives to Bitmap data, already used in many places, inculding UNO API, thus is expected to have some impact on conversion efficiency - if Cairo is used, so e.g. also headless. Change-Id: Ia638a549a04b19622892d91651317ec6727b6cd0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174266 Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com> Tested-by: Jenkins
2024-08-11	cid#1558088 COPY_INSTEAD_OF_MOVE	Caolán McNamara
	and cid#1558080 COPY_INSTEAD_OF_MOVE cid#1558077 COPY_INSTEAD_OF_MOVE cid#1558055 COPY_INSTEAD_OF_MOVE cid#1558043 COPY_INSTEAD_OF_MOVE cid#1558039 COPY_INSTEAD_OF_MOVE cid#1558015 COPY_INSTEAD_OF_MOVE cid#1558014 COPY_INSTEAD_OF_MOVE cid#1558009 COPY_INSTEAD_OF_MOVE cid#1558002 COPY_INSTEAD_OF_MOVE cid#1557998 COPY_INSTEAD_OF_MOVE cid#1557996 COPY_INSTEAD_OF_MOVE cid#1557990 COPY_INSTEAD_OF_MOVE cid#1557986 COPY_INSTEAD_OF_MOVE cid#1557980 COPY_INSTEAD_OF_MOVE cid#1557971 COPY_INSTEAD_OF_MOVE cid#1557968 COPY_INSTEAD_OF_MOVE cid#1557967 COPY_INSTEAD_OF_MOVE cid#1557961 COPY_INSTEAD_OF_MOVE cid#1557959 COPY_INSTEAD_OF_MOVE cid#1557958 COPY_INSTEAD_OF_MOVE cid#1557956 COPY_INSTEAD_OF_MOVE cid#1557953 COPY_INSTEAD_OF_MOVE cid#1557949 COPY_INSTEAD_OF_MOVE cid#1557947 COPY_INSTEAD_OF_MOVE cid#1557940 COPY_INSTEAD_OF_MOVE cid#1557931 COPY_INSTEAD_OF_MOVE cid#1557930 COPY_INSTEAD_OF_MOVE cid#1557915 COPY_INSTEAD_OF_MOVE cid#1557913 COPY_INSTEAD_OF_MOVE cid#1557910 COPY_INSTEAD_OF_MOVE cid#1557886 COPY_INSTEAD_OF_MOVE cid#1557884 COPY_INSTEAD_OF_MOVE cid#1557880 COPY_INSTEAD_OF_MOVE cid#1557875 COPY_INSTEAD_OF_MOVE cid#1557871 COPY_INSTEAD_OF_MOVE cid#1557862 COPY_INSTEAD_OF_MOVE cid#1557847 COPY_INSTEAD_OF_MOVE cid#1557845 COPY_INSTEAD_OF_MOVE cid#1557844 COPY_INSTEAD_OF_MOVE cid#1557843 COPY_INSTEAD_OF_MOVE cid#1557838 COPY_INSTEAD_OF_MOVE cid#1557835 COPY_INSTEAD_OF_MOVE cid#1557834 COPY_INSTEAD_OF_MOVE cid#1557828 COPY_INSTEAD_OF_MOVE cid#1557823 COPY_INSTEAD_OF_MOVE cid#1557817 COPY_INSTEAD_OF_MOVE cid#1557813 COPY_INSTEAD_OF_MOVE cid#1557812 COPY_INSTEAD_OF_MOVE Change-Id: I55d4a920daa2d148683419169eb828325fd3c757 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171732 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-08-02	Fix wrong / misleading uses of fTools::(more\|less\|equal) with literal 0	Mike Kaganski
	These will never compare with tolerance (the zero is a special case in rtl_math_approxEqual used internally), so the calls like those don't do what they appear to do in these cases. Change-Id: I495ac92b7f45637e118e4fdc04bb6fad6fff31ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171391 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2024-04-22	tdf#160782: convert to bitmapEx from 0,0 to width,height	Xisco Fauli
	This is the way it's done everywhere. Partially revert 4b6e0f2c88debaedb514c868e061c21e15215b6e "tdf#160726, tdf#48062: Simplify how BitmapExs are created" Change-Id: I15fea0b6855a65da7cb48b24fc00ba303e33dcf8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166456 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-04-22	tdf#160726, tdf#48062: Simplify how BitmapExs are created	Xisco Fauli
	In my initial approach, I tranformed the primitive2DContainers before converting them to BitmapEx. This caused circles like https://bugs.documentfoundation.org/attachment.cgi?id=193790 not to be displayed. Simplify how BitmapExs are created by just using the range both primitive2DContainers have in common. This way, DrawBitmapInRect can be dropped now Change-Id: I2401dc87b98e04b9cf9f5ebade2b5622d884fc3a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166391 Tested-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-04-15	Generalize basegfx::fround for templated return type	Mike 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>
2023-11-21	tdf#157558 invert and remove blended white color	Patrick Luby
	Before commit 81994cb2b8b32453a92bcb011830fcb884f22ff3, RemoveBlendedStartColor(COL_BLACK, aAlpha) would darken the bitmap when running a slideshow, printing, or exporting to PDF. To get the same effect, the alpha mask must be inverted, RemoveBlendedStartColor(COL_WHITE, aAlpha) called, and the alpha mask uninverted. Change-Id: I8e81b11aab05954c821f833f4a2fc77eec7b7701 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159742 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-10-26	tdf#157083 Artifacts in logos (gen)	Noel Grandin
	regression from commit 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: I1c269bcfa9b565258bc99c2810e960ae965f9b54 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158491 Tested-by: Jenkins Reviewed-by: Patrick Luby <plubius@neooffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-09-14	tdf#156808 force an alpha mask to be created even if it has no alpha	Patrick Luby
	We need an alpha mask, even if it is totally opaque, so that drawinglayer::primitive2d::ProcessAndBlurAlphaMask() can be called. Otherwise, blurring of edges will fail in cases like running in a slideshow or exporting to PDF. Change-Id: If03b32a8a22ed960f1475710a9831cab33799b60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156903 Tested-by: Jenkins Reviewed-by: Patrick Luby <plubius@neooffice.org>
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-12-20	Example System-Dependent PrimitiveRenderer for Direct2D (Win)	Armin Le Grand (Allotropia)
	As promised at LiBoCon'22 I have finished an example implementation of a System-Dependent PrimitiveRenderer. It renders on Direct2D, so Win only. I chose this with no special thoughts, did not even know too much about Direct2D, so had to read quite some docu. Still managed to do this in a view days. NOTE: To make it run you need to switch off skia on Win probably due to some global extra stuff done there (?) The Renderer is in a new file (ca. 1000 lines) in the drawinglayer libary. It implements all of the needed primitives, so capable of rendering EditViews (Draw/ Impress complete, Writer/Calc in parts, interactions, overlay, selection(s), etc.). It is used completely as replacement of the VclPixelProcessor2D which is not used in the patched version at all. Just one primitive is missing: - InvertPrimitive2D: Not needed much (hopefully will vanish), could also be added It is not in production state, mostly intended as a demonstration how Primitives are intended: Render without using an OutputDevice at all, directly to the traget GraphicsSystem. It can (and should) be used as pattern for other implementations. NOTE: Inside the implementation you can do whatever you want, all is allowed. Only rule is to visualize the geometry defined by the Primitives. This version does not need any buffer allocations to render and is thus pretty fast (uses ID2D1Layer). It also has no buffering, but that could easily be added. The needed classes/implementations to buffer system-dependent representations of data exist, so doable fast for Bitmaps, Polygons and PolyPolygons. It runs stable and fast, but still has errors, so it is sometimes missing to render some stuff. I would have to debug/finetune it further, but I see this all as doable. It's far enough to be seen as POC and example. I also added a not-urgently-need-to-be-implemented primitive, the UnifiedTransparencePrimitive2D, to demonstrate how to do that: Add a handler for it and render the defined geometry if you can do that more direct/better than the decomposition. The rough to-do list would be: - add missing Primitives - InvertPrimitive2D - add buffering of - Bitmaps - Polygons - PolyPolygons - add TextRendering - using decompose to PolyPolygons currently, but looks reasonably good with PolyPolygon AA - general - polishing - bug fixing - stabilization(s) - speedups by adding PrimitiveHandlers - solve problem with TransparencePrimitive2D - had to use drawinglayer::createAlphaMask there, see comments Made handling of TransparencePrimitive2D work, some fixes and changes, too. Still not happy with processTransparencePrimitive2D, it uses drawinglayer tooling (createAlphaMask) to do it's job. It works, but there must be a better way. It's okay for demonstration/POV though Tried hard in processTransparencePrimitive2D to directly render the alpha channel to a Direct2D ID2D1BitmapRenderTarget using DXGI_FORMAT_A8_UNORM. It does work theoretically as it should, but I found no way to directly paingt to the AlphaChannel. It seems as if Direct2D is hard-wired to always alpha-blend, there seems to be no control or mode to select the BlendMode to be used. Since only that small step is missing I keep that code in (see bTryDirectPreparationOfAlphaAsBitmap). NOTE: No idea yet, but testing shows that the direct but not yet complete way is ca. 7 times faster. I have now added PointArrayPrimitive2D, so only that InvertPrimitive2D is missing. I also added MarkerArrayPrimitive2D to make it more efficient (marker bitmap gets converted only once) and better looking (not AAed anymore). With both added, grid visualization looks good and is fast. Added support for BackgroundColorPrimitive2D Added BitmapBuffering for Direct2D. This is a little bit more complicated, theoretically all ID2D1Bitmaps are specific to the ID2D1RenderTarget they get created for, so theoretically they have to be (re)created every time the ID2D1RenderTarget aka OutputDevice changes - argh. There is CreateSharedBitmap though that allows re-usage of already created bitmaps for a new RenderTaget, but this leads to needing a LO-livetime RenderTarget to create all the Bitmaps for. So I implemented that and it works and is fast. Added buffering for GeometryData, ID2D1PathGeometry. I prepared this already using the CreateTransformedGeometry functionality of Direct2D, so the B2DPolygon/B2DPolyPolygon can get buffered in an unchanged form, re-used as source for creating a ID2D1PathGeometry by calling CreateTransformedGeometry. This could also be done by manipulating the current transformation, but is not necessary. Simplified buffering by directly using derivated helper classes (from basegfx::SystemDependentData) as data holders, thus they can reliably call Release() at incarnated Direct2D instances without the need to keep record of this outside. Completely removed OutputDevice from the D2DPixelProcessor2D, it was anyways only used in the constructor. Removed the need to hand over the pixel size of the pixel target when constructing a D2DPixelProcessor2D, instead get that values from HDC directly. Also made D2DPixelProcessor2D exported from drawinglayer for further experiments. Checked if I can use higher-level Direct2D versions by using MS's QueryInterface to see if involved classes are higher-level ones. This worked and allows to paint the alpha channel for TransparencePrimitive2D now indeed using the BlendMode that is missing in the initial D2D stuff, so activated that (much faster). Aded the environment variable (for Windows only) TEST_SYSTEM_PRIMITIVE_RENDERER to allow easy tesing of SystemPrimitiveRenderer. Since Skia enabled does collide in quite some places (see above) I added hat this also disables Skia in it's central isVCLSkiaEnabled() method. That way it is easy to compare/quickly change between versions. Removed maCurrentTransformation, this is just not needed for a pixel-only renderer, see comment in VclProcessor2D's header regarding that. Added snap-to-pixel functionality. Added direct support for PolygonStrokePrimitive2D, so all lines which - are fat or thin - have LineCap - have LineJoin - use dash can be directly rendered by Direct2D. This is especially good for dash since no decompositions will be created for these cases. There is an exception for our own rarely used style B2DLineJoin::NONE, that still needs to be decomposed, but could also be added to the impl if needed. There were also quite some 'conditions' for supporting B2DLineJoin::Miter in Direct2D, but I managed to solve them all, so Miter is fully done in Direct2D in this example. I also added example debug code to demonstrate how it is possible to simply add decompose paint and the system-specific implementation to optically compare and play around in a running office to identify possible problems/differences. Improved handling of TransparencePrimitive2D massively to a more future-proof and more common methodology by using the Direct2D mechanism ID2D1Effect and the CLSID_D2D1LuminanceToAlpha effect. For details, see comment in comitted code at implCreateAlpha_Direct. As explained in refs/changes/87/141087/22 I did add now a tooling derivate of D2DPixelProcessor2D that can be used to render sub-content without having to deal with patching the current internal state of the running instance, called D2DBitmapPixelProcessor2D. It resides in the cxx file (so being safe from other usages), has and creates an own ID2D1BitmapRenderTarget to work on and will come in handy for other occasions that need to prepare a in-between result. Made stuff in the renderer itself more private and added access methods to protected section, use those in tooling. Change-Id: Ie5803f9afa3f62dbaa8fd2f1bac8fd30a23066b5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141087 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-11-15	Prepare createAlphaMask to produce mask and alpha as needed	Armin Le Grand (allotropia)
	Change-Id: Ica799419ed628f94f134433ca5b37518c5698909 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142730 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-11-13	Fix typos	Andrea Gelmini
	Change-Id: Ic1fb0ea483954f2994a87e05f33b320da3795227 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142661 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2022-11-13	Adapted convertToBitmapEx to simpler BitmapEx creation	Armin Le Grand (allotropia)
	As long as not all our mechanisms are changed to RGBA completely, mixing OutDev with Alpha (2x VDev) and RGB target rendering is just too dangerous and expensive and may to wrong or deliver bad quality results (see comments in code for details). Nonetheless we need a RGBA result for convert to BitmapEx. Luckily we are able to create a copmplete and valid AlphaChannel using 'createAlphaMask'. Based n that we know the content (RGB result from renderer), alpha (result from createAlphaMask) and the start condition (content rendered usually against COL_WHITE). Tht makes it possible to calculate back the content, quasi 'remove' that initial blending against COL_WHITE. That is what the helper Bitmap::RemoveBlendedStartColor does. Luckily we only need it for convert To BitmapEx, not in any other rendering. This gives good results, it is in principle comparable with the results using pre-multiplied alpha tooling, also slightly reducing the range of color values where high alpha vlaues are used, but in areas that are highly transparent anyways. Also important is that this will work with RGB-based system-dependent renderers, too. The method before could only work with the VCL-based primitive renderers by principle (only there - by coincidence - OutputDevice with Alpha worked). NOTE: Had to re-add usage of unused alpha channel in convertToBitmapEx due to test SdPNGExportTest. It somehow creates an Alpha in Bitmap size when I remove Alpha in convertToBitmapEx, so I just keep it for now, it is created anyways, just wanted to make it sleeker. Change-Id: I12e47327f5793d6ed87e217a2355c608f528246f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142547 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-09-19	Make impBufferDevice faster again	Armin Le Grand (allotropia)
	When the Primitives for the Glow-Effects were added (modified ShadowPrimitive2D, SoftEdgePrimitive2D and GlowPrimitive2D) a modified version of impBufferDevice was created and used. That lowered the speed for drawing objects with transparence by about factor 2.5 and was unfortunately not only done for these Primitives, but for transprent objects in general. For the mentioned factor refer to: Patch to demonstrate former and now repaint differences https://gerrit.libreoffice.org/c/core/+/129301 After having reworked those Primitives to use another mechanism and being decomposed so they will work in all now and future renderers, it is possible to go back to that easier and faster method to render Transparency. For extended information, please take a look at the added comments, mainly in vclhelperbufferdevice.hxx Identified a still bad behaviour when objects use a TransparenceGradient. Corrected that and added (at this opportunity) a method 'createAlphaMask' along with 'convertToBitmapEx' which is now used in the GlowPrimitive2D & ShadowPrimitive2D which only need the AlphaMask to do their job anyways (I had commented there that thjis is possible before). That will be faster for visualizing those Primitives. Change-Id: Ieac880384de26960c2c4b8740a1dee1e15d7ac9e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140022 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-09-08	Rework of SoftEdgePrimitive2D	Armin Le Grand (allotropia)
	This is pretty much the same for SoftEdgePrimitive2D as the change for GlowPrimitive2D, so for more comments please refer to commit c2d1458723c66c2fd717a112f89f773226adc841 Added suggested change of DoSaveForVisualControl mechanism Change-Id: I28901e7a0b6e1823000d2aa6a335ce2fd80e6ce3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139585 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-09-07	Fix typo	Andrea Gelmini
	Change-Id: I4f4133ca077d69e3238aba809cd758455918bc39 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139586 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2022-09-07	ConvertToBitmapEx slightly too bright if transparency involved	Armin Le Grand (allotropia)
	Stumbled about this error when working on re-designing the blend primitives for shapes. Using convertToBitmapEx is the base for these (also for the UNO API conversion from Primitives to BitmapEx). Use a VirtualDevice in the Alpha-mode now to solve it. This creates the needed alpha channel 'in parallel'. It is not cheaper though since the VDev in that mode internally uses two VDevs, so ressoure-wise it's more expensive, speed-wise pretty much the same (the former two-path rendering created content & alpha separately in two runs). The former method always created the correct Alpha, but when transparent geometry is involved, the created content was blended against white (COL_WHITE) due to the starting conditions of the content creation. There are more ways than using a VirtualDevice in the Alpha-mode, to do this correctly, but this is the most simple for now - and I was persuaded by the following argument: Due to hoping to be able to render to RGBA in the future anyways there is no need to experiment trying to do the correct thing using an expanded version of the former method. Change-Id: I23e005f9c3723059e2b88660fede09aa83844b38 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139272 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-08-18	Move tools/diagnose_ex.h to comphelper/diagnose_ex.hxx	Stephan Bergmann
	...so that its TOOLS_WARN_EXCEPTION can be used in comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it, rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The comphelper module is sufficiently low-level for this immediate use case, so use that at least for now; o3tl might be even more suitable but doesn't have a Library until now. Also, for the immediate use case it would have sufficed to only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION, TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of include/tools/diagnose_ex.h into an additional new include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move the complete include file as is.) Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-08-14	check SetOutputSizePixel for failure	Caolán McNamara
	Change-Id: If57dbbd7f04f0ee5286cf24a00480271bd4d9f76 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138237 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-07-19	Replace old png writer in converters.cxx	offtkp
	Change-Id: I360963c2ad36a7bce5a257c9740b1e5690efc8e8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137116 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>