summaryrefslogtreecommitdiff
path: root/drawinglayer
AgeCommit message (Collapse)Author
2023-04-06tdf#152234 drawinglayer: PDF/UA export: fallback for unsupported formsMichael Stahl
veraPDF complains: Specification: ISO 14289-1:2014, Clause: 7.1, Test number: 3 Content shall be marked as Artifact or tagged as real content Form element can only be used for those form controls for which PDFWriterImpl can produce a Widget annotation; see createDefaultWidget(). For a label control, it's not editable so it's not a PDF widget. For an image button, it could be implemented in VCL but isn't currently. So a fallback is required in any case, "Figure" or "Div" can be used. Change-Id: I454030ff7c67a8a8101fcc59e945fe9dbc5f87a8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150059 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-04-04MCGR: Improve performance for texture-mapped MCGR processingArmin Le Grand (allotropia)
Change-Id: I20b32e7c272112c6c3d9f7ee0ef59c6d4d006d94 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150020 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-04-04tdf#152234 vcl,drawinglayer: PDF/UA export: produce Role for form controlsMichael Stahl
veraPDF complains: Specification: ISO 14289-1:2014, Clause: 7.18.4, Test number: 2 If the Form element omits a Role attribute (Table 348), it shall have only one child: an object reference (14.7.4.3) identifying the widget annotation per ISO 32000-1:2008, 14.8.4.5, Table 340. LO forms produce both page content in an MCID and an /Annot, so Role is needed. Change-Id: Ic231931a7c35d8da37ca76e02d97501edb43347c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149626 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-04-02SDPR: Use currently added lambda to render GradientsArmin Le Grand (Allotropia)
Change-Id: I9fba920c60690f136cae956dae17e2f5e5081f19 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149839 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-03-27tdf#152234 drawinglayer,svx: PDF/UA export: add Alt text to form controlsMichael Stahl
Specification: ISO 14289-1:2014, Clause: 7.18.1, Test number: 3 A form field whose hidden flag is not set and whose rectangle is not outside the crop-box shall have a TU key present or all its Widget annotations shall have alternative descriptions (in the form of an Alt entry in the enclosing structure elements) Form controls are weird because they have an SdrObject with the usual name/title/description plus a property "HelpText" on the control itself which is already exported as "/TU" on the /Annot unless it's empty. Exporting the SdrObject properties via ObjectInfoPrimitive2D doesn't work as tragically that is only created for form controls when painting to the screen while PDF export takes a detour that needs special handling. Change-Id: Id96f7dd13f190ab439c099cd1f4acb70c1c9fdc9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149554 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-03-26Fix typosAndrea Gelmini
Change-Id: Ib2c8055cc3caae5bab476609f8097046f1981f11 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149536 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-03-24Fix typoAndrea Gelmini
Change-Id: I8106dc197585b823b52d675698533e8a5167819b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149537 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-03-24drawinglayer: remove obsolete commentMichael Stahl
The code is now in vcl/source/gdi/formpdfexport.cxx Change-Id: I07ca1d87eedadc9778e08a491a77adc88f393586 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149468 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-03-23MCGR: Speedup Gradient Paint for VCLPixelProcessorArmin Le Grand (allotropia)
To do this, I re-organized FillGradientPrimitive2D and how it creates it's decompose. This provides the needed tooling to also do a more direct rendering in primitive processors if needed. The decompose no longer collects the matrices & colors as a 1st step in a helper data struecture (so I removed B2DHomMatrixAndBColor). It now uses a lambda function callback that hands over the matrix & color for each created step, so you can process it directly, in this case to create the needed primitives. NOTE: The decompositions are both tested. There was createNonOverlappingFill, but also createOverlappingFill that I am not sure is still used - and if in re-creating an old, strange XOR-using gradient paint mechanism in old metafiles (encapsulated with gradient info anyways), but I converted that and made sure it works. To do so I forced it to be used in paint. This is not really usable in paint since we need to paint using AA (else we would get staircase effects, esp. in new 'hard' color changes in multi-color gradients) and - as should be known - same edges painted in AA do *not* add up to full opacity, but leave behind awful 'jaggies' (e.g. opacity 0.5 and 0.5 create 0.75 and *not* 1.0). Still important to have the working geometry creation for this case. This already makes the decompose faster, but the main purpose is to use it as tooling for painting in own primitive renderers. Thus processFillGradientPrimitive2D now uses that instead of using the decomposition by default. This avoids one level of primitive creation, use that new FillGradientPrimitive2D tooling to directly create needed geoemtry & color for getting better performance (to partially compensate for potentially more expensive multi color gradients). It then paints directly using OutputDevice calls. NOTE: This can also be used in SDPRs as a 1st step to just directly and rapidly render filled single- color polygons, but of course there an implementation using the back-transformations (which are also adapted for MCGRs aleady and work) will be superior. Change-Id: I5079f76d6d8fe86007a098614c276447f2bfebce Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149456 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-03-22MCGR: Corrected error with Case16 wrong gradient shortcutArmin Le Grand (allotropia)
Also simplified using the test cases, these now depend on an ENV VAR called MCGR_TEST. Fallback is no test. For seeing a multi-color gradient use 1, for Case16 use 16. If active, all gradients are replaced with the one active for the test, 2D and 3D. This is temporary but also for pro build to check for speed there. Change-Id: I90f3c7e59d9d0a3e070a849af3f9ea1c9e5462a0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149316 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-03-22vcl,drawinglayer,svx,sw,sd: PDF/UA export: Annot StructElem for SdrMediaObjMichael Stahl
veraPDF complains: Specification: ISO 14289-1:2014, Clause: 7.18.1, Test number: 1 An annotation, excluding annotations of subtype Widget, Popup or Link, shall be nested within an Annot tag This is very similar to Link annotations, that is to say, extremely complicated to get it thought the convoluted PDF export code, with additional complication that the StructElem is produced by drawinglayer and the page annotation by sw. Put another map into PDFExtOutDevData where sw code puts stuff for the SdrObject that drawinglayer can find. The test had the problem that PDFObjectParser::parse() could not handle: <</Nums[ 0 [ 6 0 R ] 1 6 0 R ]>> Fix dropping the "1". Change-Id: If5bf7c552e26ebb7e631030b8aaecd4281e77acc (cherry picked from commit c78e90bd28cc4d6d3bde473535107784b12d9c0d) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149008 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-03-22Fix typosAndrea Gelmini
Change-Id: Iaf63fce5295f00e5d6fff020498a01a25fc0ee93 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149262 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-03-21MCGR: Model data changes for ColorSteps (II)Armin Le Grand (allotropia)
The biggest change here is to allow multiple ColorStops with the same Offset. That allows to define gradients with 'hard' color changes at any place using two ColorStops with the same Offset and different Colors. This required quite some adaptions, but works well. Also removed in this context checking for all Colors being the same to not mix up things. Also works well. Also changed the need for having Start/EndColors AKA ColorStops for 0.0 and 1.0 in place, instead 'imply' the 1st ColorStop to also define the StartColor and the last one the EndColor. This allows e.g. Gradient definitions with two GradientStops at the same Offset e.g. 0.5 with different colors to already define a full Gradient. Also added a tooling method to reverse ColorSteps, which changes the order and mirrors the Offsets (what even keeps an existing sort valid). This is useful e.g. for GradientAxial which is the only one where for decomposition the Gradient had to be interpreted 'reverse' since it's defined from center to edge, but for creating correct filled polygons to represent this the inverse order had to be used, creating polygons from edge to center. This led to 'wild' code for this one of six cases and prevented unifications with the other cases (also made your brain flip). Thus I adapted this now to use the reversed ColorSteps consequently, and the same principle loops than the other implementations to make things easier for the future and to use common tooling. Change-Id: If2943348d17d5b9cd165f4d78f22638a1dff5237 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149208 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-03-19MCGR: Model data changes for ColorStepsArmin Le Grand (allotropia)
Added tooling replaceStart/EndColor to allow simple transition for code that does not immediately adapt to multi color gradients. Also added createColorStepsFromStartEndColor for the same purpose. Adapted XGradient to no longer have Start/EndColor at all, but only use ColorSteps. Adapted all usages of XGradient to no longer use Get/Set/Start/EndColor, but access the ColorSteps instead. Replaced quite some XGradient constructors that used XGradient() as Start/EndColor since this is already the default. Adapted ColorBlending to black AKA Start/EndIntens in XGradient to work now on all ColorSteps in the required linearly-scaled manner. UNO API changes: Added com::sun::star::awt::ColorStep as basic data element that holds a pair of Offset and Color. Added com::sun::star::awt::ColorStepSequence to handle an array of sorted entries. Added com::sun::star::awt::Gradient2 derived from com::sun::star::awt::Gradient, extended by the needed com::sun::star::awt::ColorStepSequence. Added MID_GRADIENT_COLORSTEPSEQUENCE to UNO API to provide access to ColorSteps directly. Adapted XFillGradientItem::QueryValue/PutValue to make use of new UNO API data structures. To do so, added tooling methods for data transition: - fillColorStepSequenceFromColorSteps - fillGradient2FromXGradient - fillColorStepsFromAny - fillXGradientFromAny and adapted - case '0' (all data) - MID_FILLGRADIENT - MID_GRADIENT_COLORSTEPSEQUENCE - MID_GRADIENT_START/ENDCOLOR to make use of these. Tested usage of these in the office. Renamed from GradientStep to GradientStop after discussions with members on the list to make this closer related to other norms/definitions. Also renamed classes and class members to better reflect to GradientStop, so grepping/finding will be easier (e.g. 'Color' just exists pretty often, but 'StopColor' is more precise). Changed the used UNO API class for reprsenting the Color to better reflect to ranges [0.0 .. 1.0] and usage of RGB. Change-Id: I1eeb3e97e81d6785967615d1ff256551fc3b882d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148849 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-03-09crashtesting: assert seen on load of moz1297206-1.svgCaolán McNamara
Change-Id: Ide16b0086ef81bb9580b93f63c2c5220459d74d3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148478 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2023-03-05Fix typoAndrea Gelmini
Change-Id: I511583f0b8ce586fe9e6c3096597f0410c55b9fd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148263 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-03-04MCGR: ColorSteps handling moved to toolingArmin Le Grand (allotropia)
Due to the fact that handling of a vector GradientSteps will get used more often with ongoing changes I moved some handling to tooling, see sortAndCorrectColorSteps. That method sorts and corrects a vector of ColorSteps so that only valid entreis remain in a sorted order, for details please refer to the docu at function definition. I took the occasion to rearrange that to work on the single provided vector which is better for speed & ressources. Also changed the ColorStep constructor to not automatically correct constructed entries: While that is formally correct, it moves an invalid entry to 0.0 or 1.0, thus creating additional wrong Start/EndColor entries. Those may then 'overlay' the correct entry when corrections are applied to the vector of entries which leads to getting the wanted Start/EndColor to be factically deleted, what is an error. Also rearranged FillGradientAttribute to now work initially with ColorSteps, no longer requires the Start/EndColor, also adapted all usages. This securely allows start/end and in-between single-color sections in gradients. Also needed to re-formulate GradientRect & GradientElliptical ::appendTransformationsAndColors method for correct 2D mapping(s) - always incrementing from the start to end conflicts with the adaption of the start value for the inner loop mainly because increment is at start of inner loop (pre-increment). Corrected errors from clang plugin, but also some wrong initialiations for basegfx::ColorSteps. Change-Id: I292592ed9abcfa591f68a680479f4fcdda46cbeb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148196 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-03-02tdf#153672 Use RelativeMapMode so text in gdis are scaled/offset correctlyCaolán McNamara
otherwise it overrides the outer GdiMetaFiles efforts to position the origin and the text is rendered off-canvas in this scenario Change-Id: If81692dce81fb6f00d5051228e1de13cdcae1770 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148136 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2023-03-01Fix typoAndrea Gelmini
Change-Id: I6bc3777231bada3a1abf2a1e57645d9ceb93acb8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148048 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-03-01MCGR: support ColorSteps in emf exportArmin Le Grand (allotropia)
Change-Id: I7a784587dd86efee0934fdead26f615ba7f396e2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147960 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-03-01Fix typoAndrea Gelmini
Change-Id: I46f400646bc7d2b7456d294290dc2e159ba14874 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147966 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-02-27MCGR: Adapted other Gradient* to make use of MCGRArmin Le Grand (allotropia)
Added to make GeoTexSvxGradientElliptical GeoTexSvxGradientSquare GeoTexSvxGradientRect work using the MCGR. 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 all three, see the static variable nUseGradientSteps. NOTE: GeoTexSvxGradientElliptical still looks not optimal due to texture back-mapping method getEllipticalGradientAlpha, see notes in commit "MCGR: Adapted GradientRadial to make use of MCGR" ac824594c577ab4880177b3411a25297b1d08074 Change-Id: I56b82b867af88fe532f840dde15e0f5c299ed6a3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147662 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-02-25Fix typoAndrea Gelmini
Change-Id: I17a06f2cce87f6f6edb3517750e9869de9cdd5b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147668 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-02-24MCGR: Adapted GradientRadial to make use of MCGRArmin Le Grand (allotropia)
Added to make GradientRadial work using the MCGR. 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: Ie7134fe2995b23ceb180c7daf3f5b2310c8a8a78 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147617 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
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>
generated by cgit (git 2.34.1) at 2025-01-24 19:39:22 +0000