/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */ /* * This file is part of the LibreOffice project. * * This Source Code Form is subject to the terms of the Mozilla Public * License, v. 2.0. If a copy of the MPL was not distributed with this * file, You can obtain one at http://mozilla.org/MPL/2.0/. */ #ifndef INCLUDED_WRITERPERFECT_WRITERPERFECTDLLAPI_H #define INCLUDED_WRITERPERFECT_WRITERPERFECTDLLAPI_H #if defined WRITERPERFECT_DLLIMPLEMENTATION #define WRITERPERFECT_DLLPUBLIC SAL_DLLPUBLIC_EXPORT #else #define WRITERPERFECT_DLLPUBLIC SAL_DLLPUBLIC_IMPORT #endif #define WRITERPERFECT_DLLPRIVATE SAL_DLLPRIVATE #endif /* INCLUDED_WRITERPERFECT_WRITERPERFECTDLLAPI_H */ /* vim:set shiftwidth=4 softtabstop=4 expandtab: */ /option> LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/drawinglayer/source/processor2d/processor2dtools.cxx
AgeCommit message (Collapse)Author
2024-10-01CairoSDPR: Support direct RGBA for convertToBitmapExArmin 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-09-27Fix typosAndrea Gelmini
Change-Id: Ie35705bf4559f977c7a7b67edb6b05b6cd564249 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174062 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2024-09-27tdf#163125: CairoSDPR: Take virtual OutDevs into accountArmin Le Grand (Collabora)
Unfortunaletly we have 'virtual' OutDevs, that means their PixelSize is bigger as they claim and they use an internal offset. This is used to not have to create too many Windows inside Windows (AFAIR initial reason was that Windows has a fix number of Windows per process that can be incarnated). The offset was/is already supported by SDPRs using ViewInformation2D and adding ot to the ViewTransformation, but the evtl. existing PixelSize has to be clipped against. The fallback VclPixelProcessor2D supports that indirectly by doing that in the OutDev commands that get called, so it does not need to be done by that renderer. I have now added code to support that for the CairoPixelProcessor2D, see code and comments. It uses an existing method of cairo to do that elegantly inside the system-dependent code of the SDPR. Note that the Windows SDPR D2DPixelProcessor2D will have the same problem that will have to be solved there, too. Since it's currently in experimental state I made myself a note about that. Change-Id: I68915985102bb4a63c84299f8d022ab013633510 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173998 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2024-09-23Fix typoAndrea Gelmini
Change-Id: I459945f142055186fc103a2e0e7b3f347e02c680 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173822 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2024-09-23CairoSDPR: Activate globally to check builds/testsArmin Le Grand (Collabora)
This is to check all builds/tests with activated CairoSDPR to evtl. make needed additional changes as preparation to activate this in the future. adapted for testTdf139000(): Use no AA offset (0.5) for applying mask. Adapted for testDoublePixelProcessing: The trick (hack) to create a PixelProcessor and then attact a metafile to start recording to it does no longer work/make sense since the VclPixelProcessor2D is no longer the only PiyelProcessor you might get. If it is a SDPR one (e.g. CairoSDPR) it *cannot* record metafiles - and is not intended to do so. Since this test was already adapted 6 years ago to the modernized decompose of a double line to just two lines anyways it is OK to now change to use a VclMetafileProcessor2D now initially. Adapted for CppunitTest_svgio: In SvgFeBlendNode::apply execute the calls for convertToBitmapEx without AntiAliasing to get better edges. Input data is SVGToken::FeFlood, so a rectangular area, so no AA needed. Taking this back: The reason must be in the renderer, nothing else changed. Debugged in detail through both, problem is that VclPixelProcessor2D ends up in CairoCommon::drawPolyPolygon and draws the polygon AntiAliased, but just the fill and thus *not* with the AA-offset of 0.5, that is only done for fill. I have to re-consider the AA offset decision for filled polygons. Checked CairoCommon again, indeed AA offset is ony done for lines, not for fill - that corresponds with my thoghts from the weekend. Somehow this must have come in with copy/paste (?). Same is already in D2DPixelProcessor2D, have to remove there, too. Adapted for CppunitTest_sd_png_export_tests: This was a hard one, debugged all the components used for ConvertToBitmap/MaskCreation. Cumulated to be some diff in processTransparencePrimitive2D, but found no error after checking all tranmsformations. The orig errof ro the failing test (tdf#158743) seemed to give a hint, but ObjectTransformation was just handled well. At the end the diff was that VclProcessor2D uses the same processor, while CairoPixelProcessor2D creates local instances (what is cheap). Thus the content rendering for TransparencePrimitive2D was *not* using the set BColorModifierStack. Added as needed to be able to transfer that to the content rendering instance. Adapted for CppunitTest_sd_png_export_tests: Gerrit says PNGExportTests.cxx:1041 asserts, but I cannot reproduce. Maybe at the build system a slightly different font is used. My only idea is to add the mentioned point at (12,120) to the rectangles, obviously the bottom one. Next one is (13,82), again bottom one, adapting. Adapted for CppunitTest_sw_ooxmlexport16: The test 'testTdf136841' uses a WMF that contains XOR paint parts. This showed that that part in CairoSDPR did not work yet as needed. Adapted that, also the test slightly due to the color result slightly changed with CairoSDPR. One last change before activating in master: Add DISABLE_SYSTEM_DEPENDENT_PRIMITIVE_RENDERER in case it urgently needs to be switched off or to be able to simply test if something happening is related to CairoSDPR Change-Id: Idb8237a05d7594efe20edfa1707ca0002185645a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173330 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2024-08-27CairoSDPR: Make using SDPR dependent of ExperimentalModeArmin Le Grand (Collabora)
Change-Id: Ia25fe2f3c5ff4904530ea8c296d10bbbe2823af5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172394 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2024-05-16tdf#146619 Drop unused 'using namespace com::sun::star'Gabor Kelemen
now that find-unused-includes was expanded with detecting these Change-Id: I9f21ad1a85c1e3178cad98464b2ba407d909b62d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167638 Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de> Tested-by: Jenkins