summaryrefslogtreecommitdiff
path: root/drawinglayer/qa
AgeCommit message (Collapse)Author
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-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-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>
2022-11-06Remove double functionalityArmin Le Grand (allotropia)
There was processorfromoutputdevice.cxx|hxx containing createBaseProcessor2DFromOutputDevice that does exactly the same thing as createProcessor2DFromOutputDevice in processor2dtools.cxx|hxx, so I removed one onf them to make handling of future changes easier. Change-Id: Id8d49d1572a1bc39f1d330a742d4697c8c030e75 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142320 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-01-14Recheck modules d* with IWYUGabor Kelemen
See tdf#42949 for motivation Change-Id: I916f42c46efa1b6cfd7744a189b79659b2867431 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128196 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-12-16Remove transitional header drawinglayer/primitive2d/polygonprimitive2d.hxxGabor Kelemen
follow up to commit 1103727fb24b368419ea0cfd2382560ef6b82f43 Change-Id: I227042f4703f3f4c18a8dc0355f044d2ad7dfb2b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126838 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-10-16Simplify vector initialization in drawinglayerJulien Nabet
Change-Id: Iee9c13149d3614ecd9f812cfbb85e4534c33c1be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123684 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-10-06loplugin:moveparam in drawinglayerNoel Grandin
Change-Id: I428116d96a011b061dda8376b6f27fb135a62964 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123114 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-03Remove some unused includesMiklos Vajna
See tdf#42949 for motivation. Change-Id: I62354cf2ae750a91b72e91ad838a40e205e7cd61 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121526 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-05-21properly draw only parts of FillGradientPrimitive2D (tdf#139000)Luboš Luňák
The size of the whole gradient is getDefinitionRange(), while getOutputRange() gives the area of it to draw. Change-Id: I85dd7fe51bcc9c332a6fb0e6748d5ac89266b910 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115923 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-05-18loplugin:unusedfieldsNoel Grandin
Change-Id: Ib574403a7f7f8b11c6263c9c19ec6b65c8374ddd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115753 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-06add a unittest for impress drawing a dotted line in tdf#136957Luboš Luňák
Change-Id: Icabe039df29e9b3b9155656863120e3df7ef650b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115118 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-02-18loplugin:referencecasting add check for new rtl::Reference operatorNoel
rtl::Reference now has a conversion operator to uno::Reference, so look for places where we can simplify the code and use that. Change-Id: Ic81db50d670bed5e875300577d4bf5f3599cc2c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110798 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-18comphelper, drawinglayer, framework, starmath: clang-format these filesMiklos Vajna
I added these files more or less recently and they have long lines. Use clang-format to break at a sane column limit. Change-Id: Id608fffbbc0673c9bc350dd696cb0a31906840d3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94423 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2019-07-03Remove some unused includesMiklos Vajna
See tdf#42949 for motivation. Change-Id: I89c082d62409b40c8472b865cc60b0d10923c9c1 Reviewed-on: https://gerrit.libreoffice.org/75015 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-02-14CppunitTest_drawinglayer_border: use CPPUNIT_TEST_FIXTURE()Miklos Vajna
Change-Id: I73f00a0cc052173167a539be02a42c47da34dd98 Reviewed-on: https://gerrit.libreoffice.org/67793 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2018-10-25Reorganize FrameBorderPrimitive creation (II)Armin Le Grand
Step5: Move the view-dependent decomposition from BorderLinePrimitive2D to SdrFrameBorderPrimitive2D. It is now possible to use discrete sizes before the line and edge matching is done what will look much better. When it was done at BorderLinePrimitive2D and the matching was already done, that match was 'displaced' with the adapted forced scale to discrete units. The space and size used when zooming out for a single discrete unit (pixel) can heavily vary - it just covers a much larger logical area than the 'real' line/poly would do. All this needs to be handled (also for bound ranges) and can only be in a good way using primitives. Adapted to no longer do view-dependent changes in BorderLinePrimitive2D. Adapted to do these now at SdrFrameBorderPrimitive2D. Currently used to force the existing border partial lines (up to three) to not get taller than one logical unit. Adapted to no longer switch off AntiAliased rendering in VclPixelProcessor2D for processBorderLinePrimitive2D, this is problematic with various renderers on various systems (e.g. vcl still falls back to render multiple one-pixel-lines when taller than 3.5 pixels which looks horrible combined with other parts like filled polygons) All this needs fine balancing on - all systems - all renderers - all apps (which all have their own table implementation) - all render targets (pixel/PDF/print/slideshow/...) Done as thorough as possible, but may need additional finetuning. May also be a motivation to move away from vcl and implement these urgetly needed system-dependent primitive renderers... Adapted UnitTest testDoublePixelProcessing with the needed comments. Change-Id: Ie88bb76c2474b6ab3764d45a9cd1669264492acd Reviewed-on: https://gerrit.libreoffice.org/62344 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
2017-12-22tdf#42949 Fix some Include What You Use warningsMiklos Vajna
Change-Id: I30121764303579a7cb4ded0f0f48cc1f8fff6c33 Reviewed-on: https://gerrit.libreoffice.org/46946 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2017-12-06Remove unused #include <vcl/metaact.hxx> from vcl/outdev.hxxStephan Bergmann
...and fix the fallout Change-Id: Ie514bd95d5a9f990a887566619031e9844c40b92 Reviewed-on: https://gerrit.libreoffice.org/45195 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-09-15borderline: Adapted BorderLinePrimitive2D and usagesArmin Le Grand
Big changes to BorderLinePrimitive2D and BorderLine, freeing it from one/three entries, going to a free definition using gaps with width but without color. Adapted usages and creation, not yet tested much Change-Id: Ic1255a790401901c3166d200205bc23322b37185
2017-09-15borderline: Abstraction of BorderLinePrimitiveArmin Le Grand
As preparation for more detailed definition of BorderLine primitives I have adapted the BorderLine definition to work with motre possibilities to define the LineStartEnd definitions in a BorderLineExtend class. That one is flexible to hold all kinds of definitions - from none to all four possible extends (Start/End, Left/Right of vector) Cleanup of DiagStyle and others: DiagStyle is not needed anymore due to no longer using angles calculated, but being based on vectors defining the geometry. Also cleaned up quite a bit of no longer needed calculation stuff for the control.
2017-07-28borderline: corrections for calc and writerArmin Le Grand
Made corrections/finetuning for Calc and Writer. Had to remove some former code which tried to do corrections. Change-Id: Id9fc687b9a709d250faaad76c37ecfda8d8feb9b
2017-07-12borderline: correct problems with border displayArmin Le Grand
Borderline display with direct paint and with primitive direct paint has quite some errors in the current state. Started to unify usages, check deeper with creation/usage. borderline: deep changes to BorderLine Found basic error in determining the offset values for BorderLinePrimitive creation, these were not centered on the lines. Corrected that. This makes it possible to remove the formally used clipping which seems to have been used to correct that. Also allows to go back to a 'normal' decomposition that creates line primitives as expected. That again can then be painted quite normally. Also added view-dependent case to the decomposition to guarantee a gap of one discrete unit (pixel). Removed the direct painter, too. Checked and corrected stroking. borderline: Adapted previews to primitives Added code to use the primitive representation in all dialogs and apps using tables. The edit views use these mostly, so the preview should do that, too. Currently missing is a good visualization of diagonals, but this is also true for edit views. Checked all apps and table usages to not get worse borderline: correct line dash visualization When a dashed line is used, a factor of 10.0 was applied in the original coded, added that. Also the orientation of vertical borders was inverted since it was simpler to exchange Start/End, but this also mirrors the line dash visualisation, corrected that Change-Id: I4c1b380a76cb37389fab1259a53fb7cc9da982d1 e95e246d5563360617a2a2213e4d5ec7d0e736b9 62369b4de58fb0264aeb710ec6983ceddca5701d 77418cc6c84ebb0632f8c3448976e82ce612d6b6 b4eb28dc86ce05eb89b26517167305b994158ef8 borderline: adapt cppunittest and clang
2017-06-23loplugin:oncevar in cppcanvas..drawinglayerNoel Grandin
Change-Id: I5456aad61fb0dfe6830eae62b91d1a6399d6343f Reviewed-on: https://gerrit.libreoffice.org/39128 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-04-25tools: svstream.hxx needs only errcode.hxx & not errinf.hxxChris Sherlock
Change-Id: Ia28e35ae5af4f601e9a586a3deffbcd61702b0ca Reviewed-on: https://gerrit.libreoffice.org/36896 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
2017-03-17convert SvxBorderStyle to scoped enumNoel Grandin
and rename to SvxBorderLineStyle Change-Id: I19e530f162e4ca6290a0ad076e7fe3d5775ae6bc Reviewed-on: https://gerrit.libreoffice.org/35265 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-11-08reduce copying when decomposing drawinglayer primitivesNoel Grandin
instead of returning a Primitive2DContainer from each method which we are then going to immediately append to another container, pass down a single container by reference which we can append to Change-Id: I0f28a499d2ec54f7111a7044c30099767aa079e1 Reviewed-on: https://gerrit.libreoffice.org/30258 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-04-19drawinglayer, sw: indentation fixesMiklos Vajna
Change-Id: Ia84182629f33220a0d85bde00c16f9c26f45e3c5
2016-04-18tdf#99315 VclPixelProcessor2D: fix double border line widthMiklos Vajna
Regression from commit 2c91cb08d65cd35fa8ef6eaca3677aa82fb58cbe (better drawing support for borders of different width, fdo#33634, 2012-04-04), the problem is that previously the width of inner/outer double border lines got rounded to integer values quite early, but after the commit they are kept at a double precision for much longer, which needs pixel correction in VclPixelProcessor2D. Example: if the border with is 1.47, and the line gets moved by 0.2 pixels, then the inner and outer edge of the line will be 0.2 and 1.67, which gets rounded to 0 -> 2 in the pixel processor. Previously the input was rounded to 1, so moving by 0.2 resulted in 0.2 -> 1.2, which got rounded to 0 -> 1. The result is that sometimes the line width is 1 pixel wider than expected. Fix the problem by allowing VclPixelProcessor2D to request pixel correction from BorderLinePrimitive2D. It wouldn't be possible to do pixel correction only in VclPixelProcessor2D, as it has no idea what to correct: it only gets polygons, so it has no idea if e.g. the top of a polygon is the outer edge of a top border line or an inner edge of a bottom border line. Change-Id: I1971f3a952fbcdc598ab46c659e12d976c13cbe6 Reviewed-on: https://gerrit.libreoffice.org/24221 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-04-15loplugin:refcountingStephan Bergmann
Change-Id: I4f696bdb7b37da5949182d522b0d3c6c41fdc756
2016-04-15Related: tdf#99315 BorderLinePrimitive2D: fix solid line primitive widthMiklos Vajna
Regression from commit 2c62596cf264ef10749d8bfdb2bb2ebef2d98fbc (fdo#75260: Correctly draw double lines for both Writer and Calc., 2014-03-03), the problem was that when decomposing a double border line promitive to solid line primitives (which happens for the legacy "border" type, while both the Calc UI and Excel importer creates "border-thin" ones), the decomposed inner line's height was larger than the requested width. As a result there was no gap between the polygon of the inner and the outer line of the double border, looking like a non-double border. The width of the outer border is still incorrect on the screen, though. Change-Id: Ia9713c315ce8f23e2579b257169798e7c82c0a64 Reviewed-on: https://gerrit.libreoffice.org/24115 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
generated by cgit (git 2.34.1) at 2025-01-25 17:32:48 +0000