summaryrefslogtreecommitdiff
path: root/drawinglayer
AgeCommit message (Collapse)Author
2023-02-23MCGR: Adapted GradientAxial to make use of MCGRArmin Le Grand (allotropia)
Added to make GradientAxial work using the MCGR as 2nd of six types. This one was complicated since it uses the gradient(s) 'reversed' when you look at it, from outside to inside. Had to do quite some tickeling to get it all work, but looks good now. For modifyBColor I Could re-use the started tooling as planned. To get the reverse usage working I ended up in 1st adapting the previous usage to make more use of std::iterator and reverse_iterator to be able to use the reversed state of the ColorSteps more 'controlled' as if trying to adapt the numerical indices to the vector (that ended in chaos). It is still 100% backward-compatible, so as long as there is no source using this it will stay invisible - by purpose. Tests look good with this one, see the static variable nUseGradientSteps. Change-Id: I0117ec9a24b5e55869b3e2741c67fb87b549db97 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147510 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-02-22Fix typoAndrea Gelmini
Change-Id: Ibb51b7ea2a404156459fb7454e5260d0375fc842 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147472 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-02-22MCGR: Adapted GradientLinear to make use of MCGRArmin Le Grand (allotropia)
Added to make GradientLinear work using the MCGR as 1st of six types. Had to do quite some tickeling to get it all work, but looks good. Five more to go, already started to put some things to tooling to make re-usable for the other types. Besides adapting this the main change is that the adaption of defined step-count (versus automatic) has to be done in modifyBColor now instead of the back-mapping methods (e.g. getLinearGradientAlpha). It is still 100% backward-compatible, so as long as there is no source using this it will stay invisible - by purpose. I started to do quite some tests (and fixes/ adaptions in consequence), see the static variable nUseGradientSteps. If you want to play with this, you might set it to '1' instead of '0' and use a linear gradient on an object. Change-Id: I9d61934defb0674456247f2879f0a89b6a5e50f7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147413 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-02-19osl::Mutex->std::mutex in BasePrimitive3DNoel Grandin
Change-Id: I49e196885845f352c6c4cda6e3890b749d4eb0fa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147263 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-02-15MCGR: Add GradientSteps to GeoTexSvxGradientArmin Le Grand (allotropia)
Move GradientSteps data to GeoTexSvxGradient and adapt interfaces. Also move tooling to more isolated place in gradienttools in basegfx. Keep everything still compatible, the work will be now to adapt all six different derivations of GeoTexSvxGradient to make use of the evtl. given GradientSteps. Change-Id: Iaa212763c603d46de0a94b1b203b979bb7ce359d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147050 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-02-12Fix typosAndrea Gelmini
Change-Id: I7c755b2099c3607fece3442269ff3a806b196f1f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146836 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-02-12MCGR: Add/Provide GradientSteps to FillGradientAttributeArmin Le Grand (allotropia)
MCGR stands for MultiColorGRadient. This change allows/ prepares adding multiple color steps to gradient rendering. This is preparation work to allow rendering MCGRs in the future. All places are adapted in a way that currently no change of behaviour will happen. It will be the base to get MCGR rendering/decompose for Primitives and our internal/existing gradients working. Change-Id: I28bbd7d10b8670042343ada2a66b5909d3d31bbd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146748 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-02-07improve readability of VirtualDevice constructorNoel Grandin
(a) It is not obvious what DeviceFormat::DEFAULT means (b) There are two parameters (each with two states), but only really 2 possible overall states So (1) use more useful names (2) combine the two parameters into one enum Change-Id: Ic0595b39e032cc9e019b88326389d055b977da00 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146589 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-25tdf#153092 text appears missing with font sizes < 1Caolán McNamara
where the size is scaled up, so restore use of scaling up when necessary. But continue to use unscaled supplied values when provided integer sizes to avoid scaling down. Change-Id: I8de268d1c9ac8f0a75aa84e231812b12310db76a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146140 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2023-01-21SDPR: Unified some stuff & moved to toolingArmin Le Grand (Allotropia)
Added and unified usage of a helper to create primitive sub content easily, also for visibility checking of primitives. Some smaller cleanups, too. Change-Id: I3c4cd3e98e62b8cf7984351dbb0b154470fd8e3c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145908 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-01-18SDPR: Add support for InvertPrimitive2DArmin Le Grand (Allotropia)
We urgently should get rid of XOR paint, modern graphic systems allow no read access to the pixel targets, but that's naturally a precondition for XOR. While we can do that for the office's visualization, we can in principle *not* fully avoid getting stuff that needs/defines XOR paint, e.g. EMF/WMF imports, so we *have* to support it (for now - sigh)... This makes this renderer complete from the minimal to-be-supported primitives, too. Change-Id: Ie8fa98b777de764af0babe969296a671ca5cc7ce Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145739 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-01-18Fix typoStephan Bergmann
...which happened to go largely unnoticed (the would-be additional overload, as seen when including drawinglayer/processor2d/SDPRProcessor2dTools.hxx first thing in drawinglayer/source/processor2d/SDPRProcessor2dTools.cxx, was just never defined nor used), but caused > drawinglayer/source/processor2d/SDPRProcessor2dTools.cxx(140,6): error: externally available entity 'prepareBitmapForDirectRender' is not previously declared in an included file (if it is only used in this translation unit, make it static; otherwise, provide a declaration of it in an included file) [loplugin:external] > bool prepareBitmapForDirectRender( > ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ with clang-cl Change-Id: I9f338dd998b66fe3223af045206a423b016b93f3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145696 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-01-17SDPR: use correct Viewport for sub rendererArmin Le Grand (Allotropia)
Change-Id: Ia10731fbe44c812120ed6594959ddee909568187 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145666 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-01-14Fix typos and exec bitsAndrea Gelmini
Change-Id: Ia23a7b507a8254a5d9143de055c28da9656425fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145515 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-01-14Fix non-PCH buildThorsten Behrens
Change-Id: I70c82cece35585b7021c8adef835cc76112c68a4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145512 Tested-by: Thorsten Behrens <thorsten.behrens@allotropia.de> Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2023-01-14tdf#152990 set the font after the MapMode is (potentially) setCaolán McNamara
Change-Id: I64617a5c85e7e6b444aac705ebbfdd777b4ea55a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145487 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2023-01-13SDPR: Direct support for FillGraphicPrimitive2DArmin Le Grand (Allotropia)
Added support to directly paint FillGraphicPrimitive2D, that means object fill with multiple tiles/tiled fill. Note: This may use not only bitmap data, but also metafile or svg. The standard decompose creates one transformed bitmap/vector data primitive per tile what is correct, but has some limits (a) These may get many when tiles are small compared to mask polyPolygon (performance/ressources) (b) Correctness: when rendering in AA the common edges of tiles will *not* sum up perfectly, but due to AA multiplying when blending will leave ugly 'traces' This direct rendering avoids both. It can use the D2D Brush functionality to repeat. Additionally to the current office it can also do that when content is rotated/sheared. This may not be well known since for those fills the office always keeps the fill unrotated (for historical reasons, primitives can do that, but not vcl). To see it you may convert a SdrObject to metafile and rotate that, so the content gets rotated and shows that ugly gaps. Also added a square-pixel step value for vector fills where the default gets used starting from some size. The argument is better quality for vector data fills while only a limited number of tiles will be rendered. Also added a buffered handling of the (old and ugly) OffsetX/OffsetY to make that work, we will not get rid of that soon. Packed all of this into tooling (so started a tooling collection for SDPRs target-system independent) to be able to easily re-use all these preparations/tests in other SDPR implementations in the future. Change-Id: Iafacf4181e7c9e2d2b2e3b5cf1f7e4cdd0a43f0a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145466 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-01-12loplugin:unnecessaryoverride (clang-cl)Stephan Bergmann
Change-Id: Ib0f721cb0bb7ebfd3b422cfb9e93804a70e1270b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145381 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-01-12drop internal support for 1-bit imagesNoel Grandin
on modern hardware, these are less efficient than regular alpha channels. Also, this greatly simplies the range of stuff that vcl needs to deal with, which will make the upcoming transparency->alpha patch easier to deal with. Enhance vcl::CreateFromData to convert incoming 1-bit data to 8-bit image. Change-Id: I35829da750029fe373d0d2911a669d10bab6ad23 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145321 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-11rename BitmapEx::GetAlpha to GetAlphaMaskNoel Grandin
to ease the reading of code related to an upcoming patch to convert transparency to alpha, since there is already a GetAlpha in Color. Change-Id: I1af0f8f6dd94acfe4673c8556c7aff6c20da3f7a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145209 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-06Fix typosAndrea Gelmini
Change-Id: Ia565446bab6436940954bc1af10f612cb9a9ad9b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145152 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-01-06SDPR: Overhauled D2DRenderer to use sal::systools::COMReferenceArmin Le Grand (Allotropia)
All stuff used from MS with names starting with ID2D1* is COM API stuff, so referenced and interface-based. I thought about making this more safe since a while (shared/unique_ptr, ...) but found no good way to do it. Also did not want to use CComPtr from MS and expand the devenv we need on win, so was short before doing an own small smartptr class. Luckily I asked sberg and he pointed me to the already existing sal::systools::COMReference which exactly does what I need here - thanks! Unluckily I now had to change a lot of code - sigh. I wish I had known earlier :-/ This change contains the renderer completely adapted to using that much safer and better ressource control. Plus I added (even more) comments to try to make more clear in many plasces what's going on, what is done and why. Change-Id: Ia2aa3223d0e5f7ec6569cde176cec1fadcd921dc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145142 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-01-06Removed executable permission on source fileAndrea Gelmini
Change-Id: Ida56746e5f2442ceff86e19cf52467dc766a95ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145113 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-01-05Fix typosAndrea Gelmini
Change-Id: I49ca0e4e05420a4992acc348a3dc6e3533f4d30e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144618 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-01-04SDPR: sync with "Corrected some transformations in Direct2D renderer"Caolán McNamara
Change-Id: I19a652390e803f4c60466ce7796ddfeda2ef27c1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145023 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2023-01-03SDPR: Corrected some transformations in Direct2D rendererArmin Le Grand (allotropia)
Change-Id: Icd478d61e0941edb6f3420267fe425ba1d5b8dc8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144988 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-12-29cid#1518242 Logically dead codeCaolán McNamara
Change-Id: Ie0a426c207746cca19b652a51b6f567e4b9a0752 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144860 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-12-23SDPR: Add rendering of BitmapPrimitive2D for CairoCaolán McNamara
pretty nasty copy of bitmap data for split alpha and so on, head scratching for a while to figure out to scale the pattern matrix, but it seems to render ok Change-Id: I6c82953e3646556ece6b1a5a6b12b7f76b0d41c6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144774 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-12-22-Wc++11-narrowing (clang-cl)Stephan Bergmann
("non-constant-expression cannot be narrowed from type 'double' to 'FLOAT' (aka 'float') in initializer list") Change-Id: I079ec4b6cc5e757e4082ebc6b9ae6d06065542eb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144738 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-12-22loplugin:redundantstatic (clang-cl)Stephan Bergmann
("salhelper::SimpleReferenceObject subclass being directly stack managed, should be managed via rtl::Reference, const primitive2d::PolyPolygonColorPrimitive2D") Change-Id: I53246ac9f1af1eb1d1ad91ef4d5f59dc19fd2825 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144742 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-12-22loplugin:redundantstatic (clang-cl)Stephan Bergmann
Change-Id: I2bc5a6231c78e8a38dd65ec0310b0b2b68f6fb22 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144741 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-12-22-Werror,-Wshadow (clang-cl)Stephan Bergmann
Change-Id: Ib73b837ea23c2292877e77772ac80ea88f99a713 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144737 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-12-22loplugin:redundantfcast (clang-cl)Stephan Bergmann
Change-Id: Ie8fab41974392ddd3774b95ddee6c28e41cb5c36 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144739 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-12-22Added names for new Primitives to idToString (II)Armin Le Grand (allotropia)
Change-Id: I43aa64afdd6b92beddc8484daa97babf4d6a6745 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144690 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-12-22Corrected errors when Blur effect was re-used in shadowArmin Le Grand (allotropia)
For GlowPrimitive2D and SoftEdgePrimitive2D I had to correct the view-dependent decomposition in the case where shadow was activated for the shape that was used. That creates an extra transformation, e.g. shadow offset, that needs to be taken into account, here by operating in discrete view- coordinates to solve the problem. NOTE: This is not needed for ShadowPrimitive2D itself when ShadowBlur is used due to the primitives this is based on are already handled with the needed offset. Change-Id: I87dd8db9467fbd27008d6154b78599f28057ce45 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144693 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-12-22Fix typoAndrea Gelmini
Change-Id: I996d18f76a04f822712687755b0ad51aa287d354 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144713 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2022-12-21sync with latest additions to d2dpixelprocessor2dCaolán McNamara
commit 7d948d5c7edbbfd29a77b97a5101aa43917e5ec2 Date: Tue Dec 20 18:42:42 2022 +0100 SDPR: Add handling/direct rendering of some simple Primitives Change-Id: If5432ac02f51f4b9194ec5df347f93e11f58959b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144694 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-12-21initial Experimental System-Dependent PrimitiveRenderer for CairoCaolán McNamara
just some partial pieces export TEST_SYSTEM_PRIMITIVE_RENDERER=1 and the simple drawing shapes work Change-Id: I3e01501a1cb21ec86d6fe8f5637a23e7358ffc86 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144632 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-12-20SDPR: Add handling/direct rendering of some simple PrimitivesArmin Le Grand (allotropia)
(SDPR == SystemDependentPrimitiveRenderer) Make D2DPixelProcessor2D directly render the added simple Primitives LineRectanglePrimitive2D FilledRectanglePrimitive2D SingleLinePrimitive2D to use less ressources & get faster since no conversion to Polygons is done. These are Primitives that *may* be handled directly, but do not have to - I checked that the decomposes do work before adding direct handling. Change-Id: Ifa97c595c262d84a9889f92571b2c9909bcef0e0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144626 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-12-20Fix no-pch buildMike Kaganski
Change-Id: I913760fe4cb479ae1396512beed3b04e9275825f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144607 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-12-20Added two simple tooling Primitives for easy/common casesArmin Le Grand (allotropia)
Added three simple tooling Primitives: (1) SingleLinePrimitive2D: Just a Line from Point A to B with a BColor, decomposes to a PolygonHairlinePrimitive2D (and to a PointArrayPrimitive2D if only a single point aka A == B) (2) LineRectanglePrimitive2D: (3) FilledRectanglePrimitive2D: Rectangles that support fill or line, gets decomposed to maybe PolyPolygonColorPrimitive2D (if filled) and a PolygonHairlinePrimitive2D (if line) or nothing if the B2DRange is empty NOTE: If using these despite being hor/ver aligned due to their nature as B2DRange(s) (aka 'non rotated/sheared') these may have to be transformed if the current transformation context you are working in is rotated or sheared, so *ensure* to handle these correctly if you do handle them yourself. This is not needed with the Polygon-based ones - that's why these are - and stay - the common case(s). Both are hairline primitives themselves, so are potentially *view-dependent* (see comment in *.cxx and *.hxx). They will be useful as very simple primitives for small renderers, e.g. to avoid conversion from rectangles or just lines to polygons. The more general Primitives are always the polygon-based ones, so these new ones get decomposed to these (decomposition direction, complex -> simpler). This assures that a processor/renderer has minimally to support the polygon-based ones, but *can* use these simple tooling ones directly if he wants to. This will come in handy for future System-Dependent PrimitiveRenderers, which I am currently working on one to offer as example - this leads to identifying helpful upstream things that will come in handy in that regard - like these ones. Change-Id: Ie5039e6cfad6c9914c165cae6f8b59abecc38302 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144543 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-12-20Example 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-12-19remove dependency from drawinglayer to frameworkNoel Grandin
to try and untangle the dependency mess a little. This means (*) tunneling a piece of information from VCLXWindow via the XWindowPeer::getProperty method, so we do not need to directly call VCLXWindow. (*) moving some formpdf code from framework "down" to vcl, where the drawinglayer code can use it Change-Id: I2c1ff3e34941b3147e66cf0a2d0fdb13293e3aa2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144341 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-12-02tdf#152094 retain more accuracy from RefDevMode::MSO1Caolán McNamara
do it like this to avoid adding another mapmode and to keep things "the same" as much as possible Change-Id: I1965aa545646f2d27b950d6335b2f608c3e4e04b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143475 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-12-01drawinglayer: add StructureTagPrimitive to XML dumpMichael Stahl
Turned out to be unnecessary but why not add it. Change-Id: I8dac0f0d6ec47f98d540eb4f8c42830cd652f344 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143536 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-12-01tdf#135192 drawinglayer,svx: PDF/UA export: also tag TH for SdrTableObjMichael Stahl
There isn't really an indication of anything being a header row, but the table template application has a flag to apply special formatting to the first row, so let's use that as indication that it's a header row Change-Id: Ic361c84d9a1a4e91109d6f9d2cd626c9633b311f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143500 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-12-01OutputDevice::GetTextArray will always set the size of the vector anywayCaolán McNamara
Change-Id: I52f24e50455c0d480f8976ee63e442008c05c192 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143520 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-12-01Handle PolyPolygonGraphicPrimitive2D with used DefinitionRange correctlyArmin Le Grand (allotropia)
If the range which defines the bitmap fill is defined and different from the range of the defining geometry (e.g. used for FillStyle UseSlideBackground) this cannot be expressed in a SvtGraphicFill data package. Thus, just use decomposition here directly. See also tdf#149754 in drawinglayer/source/processor2d/vclpixelprocessor2d.cxx and the comment there for more info. Change-Id: I8e1b26fb2bf523e6fd7af1040166f8197747e7ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143503 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-11-25tdf#57423 drawinglayer: PDF/UA export: more Alt texts for SdrObjectsMichael Stahl
Currently /Alt texts are generated from ObjectInfoPrimitive2D, but this is only evaluated in VclMetafileProcessor2D::processGraphicPrimitive2D() so while it's created for every SdrObject, it's ignored in most cases. There doesn't appear to be a reason why this is done in processGraphicPrimitive2D() and not a more generic location, the special conditions that are checked there don't have anything to do with Alt texts, they effectively guard some optimisation done to bitmaps in PageSyncData::PlaySyncPageAct(). There is another issue in that not every SdrObject gets a StructureTagPrimitive2D, and even if there is a StructureTagPrimitive2D it may be ignored if it's in the background. The Alt text must only be produced if there is a structure element for the same SdrObject, else it would end up on some unrelated structure element. Fix all this by moving processing to a new function which checks that there is a current StructureTagPrimitive2D for a SdrObject in effect. The only problem with this is that previously Writer images produced Alt text, and now they don't - but Writer needs some fixing anyway. Change-Id: I2a362e8a9cd93e5bc817c6eed546c46b46e14980 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143189 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-11-23loplugin:unusedfields make some fields privateNoel Grandin
this is one of the secondary analyses this plugin performs Change-Id: Iaa4424c2396470c6f1df85b0290fbffdda35fa08 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143177 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>