summaryrefslogtreecommitdiff
path: root/canvas
AgeCommit message (Collapse)Author
2022-10-18tdf#42982 Make UNO error reporting more descriptiveCalvince Otieno
Change-Id: I1f1c8285a1d41a9c9694a54c0bdfb20c6f0b27ed Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141512 Tested-by: Jenkins Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2022-10-17tdf#145538 - Use range based for loopsOmkarAcharekar
Change-Id: Ia4f795dc9bb59b6d1ee54daae49ac195bbc92a0f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141434 Tested-by: Jenkins Reviewed-by: Hossein <hossein@libreoffice.org>
2022-09-11basegfx: replace typedef with a class B2DSize based on Size2DTomaž Vajngerl
Change-Id: Id8b3c2bcf0bf4be5aba2812b0edda479bc20c6a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139683 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-08-18Move tools/diagnose_ex.h to comphelper/diagnose_ex.hxxStephan 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-14tdf#104921: Cleanup Kashida insertion logicKhaled Hosny
Communicate Kashida insertion positions in an explicit way. Rest of LibreOffice communicate adjustments to character widths (e.g. for justification or spacing) using so-called DX array. DX array is an array of absolute character positions (e.g. DX[n] is the position after character n from the start of the lines, and its widths is DX[n] - DX[n-1]). This DX array is modified also when Kashidas are inserted after a given character for Arabic justification, by expanding its width. VCL would use this to know where to insert the Kashidas and how many ones. But because DX array is used for both widths adjustments and kashida insertion, this turns out to be a source of bugs since VCL has tosecond guess the DX array to find which is pure width adjustment and which also involves Kashida insertion, and the heuristics it uses are fragile. This change adds a second array of booleans that records where Kashida is inserted and communicates it all the way from where Kashida insertion is decoded in Writer and down to VCL layout. This change passes the Kashida array only when it seems necessary (e.g. during drawing but not when measuring text since the DX array is enough in this case). Hopefully no places where Kashida insertion needs to be passed down were missed. A couple of glyph and layout flags that were used for old heuristics and no longer needed and are removed. This also fixes: tdf#87731 tdf#106309 tdf#108604 tdf#112849 tdf#114257 tdf#127176 tdf#145647 tdf#146199 Change-Id: I4ed0850ef2fdc3e9143341afac649e7e7d463c39 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138068 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-05-21clang-tidy modernize-pass-by-value in canvasNoel Grandin
Change-Id: Ib6e1b6182d83b09dbf5e2aeb9cf3e4ca11d9f48b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134712 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-05-19loplugin:redundantcastStephan Bergmann
Change-Id: I1d9bebc5bc0b32e71694915070a8770b3ca601c3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134606 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-05-09tdf#147021 Use std::size() instead of SAL_N_ELEMENTS() macroPragat Pandya
Change-Id: I54257e87da0cd66da59d820c7960c3e4b020fda3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134027 Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl> Tested-by: Jenkins
2022-05-05Just use Any ctor instead of makeAny in canvasStephan Bergmann
Change-Id: Iade345e814f2809bead96b228afa925d86057696 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133847 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-04-10loplugin:stringview check for getToken and trimNoel Grandin
since we now have o3tl versions of those that work on string_view. Also improve those o3tl functions to support both string_view and u16string_view Change-Id: Iacab2996becec62aa78a5597c52d983bb784749a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132755 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-03-28Drop support for OpenGL denylist on X11Stephan Bergmann
...which appears to have become even less relevant with db89f53c31af997b9bf422b0e784afba8d62a42e "remove OpenGL VCL backend code". And the vcl/unx/glxtest.cxx machinery that it is based on is (a) known to cause issues like <https://gitlab.freedesktop.org/mesa/mesa/-/issues/3957> "LibreOffice's OpenGL version detection code hangs when running inside a flatpak container with a different mesa version", and (b) is one of the two reasons why an soffice that uses Wayland nevertheless also requires Xwayland during startup (the other reason being oosplash). So getting rid of the glxtest machinery is beneficial. The remaining two potential uses of OpenGL on X11/Wayland are the obscure css.rendering.SpriteCanvas.OGL service implementation (about which db89f53c31af997b9bf422b0e784afba8d62a42e states that "it seems has never been finished or enabled (or so it most probably should be dumped too)") and some slideshow transitions. About the latter, Caolán stated on IRC: "I think we grew this set of stuff to check for dodgy opengl primarily for the case where vcl used opengl for ordinary UI optimizations; but I think that use is gone now so I wonder does it make sense to just drop all of that entirely; for just slide transitions we apparently survived fine without the denylist for ages". (And in any case there is still the WatchdogThread support with OpenGLZone::hardDisable in VCLExceptionSignal_impl, vcl/source/app/svmain.cxx, should any OpenGL code run into problems.) (The removal of gb_LinkTarget_use_glxtest from gb_LinkTarget_use_vclmain, which indirectly brought in gb_LinkTarget_use_libraries,*,vcl, revealed that an explicit use of vcl was missing from various Executables etc., which thus had to be added now.) Change-Id: Ifa5220fd09910a4459ca546d9655e479a2e38f1e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131943 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-02-01adjust gradient drawing in vclcanvas (tdf#144073)Luboš Luňák
For whatever strange reason the drawing does not use the given geometry, but something bigger. When I added direct drawing using VCL in a46cb5dc607d1d1af402ff3e8fce731e7427854d I naively assumed that the drawing area for the gradient would be the given area. Change-Id: Ia62cb0e5046e622679143eef56a3c6782781bf59 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129298 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-01-13Recheck modules [a-c]* with IWYUGabor Kelemen
See tdf#42949 for motivation Change-Id: I74a3c3a67c3639376e2251c3eb917fa4139dfbd0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127808 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-01-12gbuild: build static LO / link static executablesJan-Marek Glogowski
This allows to build a complete static LibreOffice on Linux, except for linked externals. Since LO's static build implies disabled dynamic loading, one must select one VCL backend to be compiled in. See the (large) comment in solenv/gbuild/static.mk trying to explain, why this implementation was chosen (spoiler: seems there is no other way) and what is actually implemented. This will collect all libraries, statics and externals of executables. If the executable uses components, it will get linked to all static components. While it works with any Executable, it just makes sense for soffice.bin, because the static component map sucks every dependency in, bloating most other binaries. In theory on could generate the dependencies based on the list of used components (see gb_CppunitTest_use_components), then generate a specific static constructor map, directly include it in the exe's cxx code and then link the minimal dependencies. The static LO should build on Linux with: --enable-customtarget-components --disable-dynamic-loading Tested VCL plugin config is: --disable-gtk3 --disable-gen --enable-qt5 The partial build support is split into a 2nd patch. Change-Id: Iafc95752fae9e88095f54a21f1e30a4f080815e2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126790 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-12-25pass unique_lock as param in WeakComponentImplHelperBase::disposingNoel Grandin
so that subclasses can drop the lock while calling listeners Change-Id: I6105438110af08f10b0ed50057b28172c3442b95 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127434 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-12-24use comphelper::WeakComponentImplHelper in ParametricPolyPolygonNoel Grandin
Change-Id: I923970389870ced5e8e310c0f73859117b1cedb9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127405 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-12-22loplugin:unusedvariablecheckStephan Bergmann
Change-Id: I02b42dc4a825e01363e36d6a82f78519e2c6dfe7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127294 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-12-21loplugin:flatten in canvas..cuiNoel Grandin
Change-Id: I208767eaa60d913fe2882403f1f9351eb08256f7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127224 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-12-13Refactor some buildsytem stuff (mostly whitespace)Jan-Marek Glogowski
Change-Id: Idfca786ecc7251e08525bd5b45936143727c43d3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126731 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-12-10Revert "Re-Enable DrawTransformBitmapExDirect for render backends"Armin Le Grand
This reverts commit 7e5af164b7d293dd410710bed411e1ca64bbecf7. Reason for revert: Not the best/effective way to clear out the stuff remaining to be done, would need additional stuff Change-Id: Ia6ab90384da29a5e34eff0ab8881bad2ab49c58c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126601 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2021-12-10Generally determine Rdb content from gb_*_set_componentfile callsStephan Bergmann
...instead of by listing the content somewhat redundantly in the Rdb_*.mk files, to avoid duplication of logic for components that are only built conditionally (and thus should only be included conditionally in the corresponding Rdb). To achieve that, add an "rdb" parameter to gb_ComponentTarget_ComponentTarget (and to the gb_*_set_componentfile macros that internally call gb_ComponentTarget_ComponentTarget), which is used to make the appropriate gb_Rdb_add_component call internally from within gb_ComponentTarget_ComponentTarget. (As a special case, gb_CppunitTest_set_componentfile shall not call gb_Rdb_add_component, as that has already been done by the corresponding gb_Library_set_componentfile call, so allow the gb_ComponentTarget_ComponentTarget "rdb" parameter to be empty to support that special case.) Most Rdb_*.mk files are thus mostly empty now. One exception is i18npool/Rdb_saxparser.mk, which duplicates some of the Rdb_services content as needed during the build in CustomTarget_i18npool/localedata. 1c9a40299d328c78c035ca63ccdf22c5c669a03b "gbuild: create services.rdb from built components" had already tried to do something similar (in addition to other things) under a new --enable-services-rdb-from-build option. However, that approach had four drawbacks that this approach here addresses (and which thus partly reverts 1c9a40299d328c78c035ca63ccdf22c5c669a03b): 1 Rdb_services shall not contain the component files of all libraries that are built. While that commit filtered out the component files that go into Rdb_ure/services (ure/Rdb_ure.mk), it failed to filter out the component files that go into others like Rdb_postgresql-sdbc (connectivity/Rdb_postgresql-sdbc.mk). 2 The code added by that commit to Makefile.gbuild codified the knowledge that there is an Rdb_services, which is brittle. 3 The code added by that commit to solenv/gbuild/Rdb.mk codified the knowledge (for gb_Rdb__URECOMPONENTS) that there is an Rdb_ure/services, which is brittle. 4 Introducing an --enable-services-rdb-from-build option needlessly provided two different ways how the content of Rdb_services is assembled. The changes done here would leave --enable-services-rdb-from-build as a misnomer, as it no longer controls how Rdb_services is assembled. I thus renamed it to --enable-customtarget-components, as that is apparently what it still does now. Change-Id: Ia5e8df4b640146c77421fcec6daa11a9cd260265 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126577 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-12-07Re-Enable DrawTransformBitmapExDirect for render backendsArmin Le Grand (Allotropia)
Unfortunately the add/usage of HasFastDrawTransformedBitmap did disable the system-dependent implementations/fast-path for DrawTransformBitmapExDirect and it's implemenations, except for Skia. This means that the current backends for Windows/Mac/Cairo/headless/Qt5 have to do expensive pixel operations when a Bitmap is 'really' transformed (rotate/shear) since some time. The nine implementations using ::hasFastDrawTransformedBitmap (grep for it) all return false, except the Skia one. Since HasFastDrawTransformedBitmap() uses that and itself is used in the very central mehod OutputDevice::DrawTransformedBitmapEx(...) to decide if that fast-path shall/can be used at all, it was *no longer used* - except for Skia - what makes Skia definitely performing better with transformed Bitmaps, or the other way around - the others worse. HasFastDrawTransformedBitmap() is used in only two places, the second is in the canvas helper to decide if to try to use that fast-path for presentation rendering. A method at OutputDevice to see if that fast-path is implemented is therefore currently needed, but for the canvas helper only. Since this will/should be converted to primitive usage (hopefully) anyways, nine impementations calling these virtual functions often and the danger to produce a mismatch/ error beween implementations of hasFastDrawTransformedBitmap and drawTransformedBitmap (as happened here, but can also happen when someone adds or removes an implementation) I looked for a way to solve that differenly and more safe. Since SalGraphics::DrawTransformedBitmap anyways returns a bool to signal it's success I take this as base to implement a buffered test directly at SalGraphics, also directly set a local flag to detect that functionality if DrawTransformedBitmap is used anyways before the test is/would be needed. Combined wih that small test to check only if this was not yet used and thus tested by DrawTransformedBitmap anyways I can offer a reliable non-virtual method at OutputDevice called ImplementsFastDrawTransformedBitmap() that will be used at the single necessary location - in the canvas helper. Since that small test direcly uses one of the nine implementations of hasFastDrawTransformedBitmap it is fundamenally more reliable and probably the copy bitmap/writeBack never really used (I tested that it works) due to an earlier use of DrawTransformedBitmap did the check potentially already. I also took a look at the cairo version (since I had this one running here) and ensured that the buffering of the system-dependent form of the Bitmap as cairo surface still works. Regarding the newly introduced fAlpha parameter I want to add some remarks: - It should be called fOpacity to make clear that it describes opacity, defining that if 1.0 == fAlpha means *no* transparency. That word is used in other graphic systems and makes more clear what function it has. It is the opposite of transparency, but works the same. - Currently all implementations of ::drawTransformedBitmap - except Skia where it was implemented - do not use it, but return false. It will in most cases not be too complicated to add/implement it, e.g. for cairo anyways a transparency surface will/is created, fAlpha can just be merged in, and the criteria for buffering that may be extended to remember for which value (if at all) of fAlpha that was prepared. I strongly recommend implementing these for our main graphic backends. - The primitive renderer uses another more general way to add an extra alpha channel to paint when needed - it draws the content (any content) that needs to be transparent to a buffer and then that buffer using the intended transparency. This is discussable since may be more expensive, but more general and keeps the interface less complex. We can see here that adding that complexity to the existing interface at OutputDevice makes the implementations more complex what might be the reason his was only implemented for one of nine backends. When adding something like this and extending the complexity I would prefer that at the same time it gets also *implemented* in all or most or at least most used cases. I want to make clear that from my POV in those cases choosing possible runtime speed over complexity is not always preferable. Change-Id: I5bab59f59fca878a7b11a20094e49e8b50196063 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126480 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2021-11-19Drop F_PI1800/F_PI18000, and unify deg2rad/rad2deg conversionsMike Kaganski
Change-Id: Ib89b00c3dc8cd440e8a88906eea133becd1cef64 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125509 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2021-11-19Use M_PI* instead of F_PI*Mike Kaganski
Change-Id: Ie2b7a1c74fc516781a17a20157b8217bc41e383d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125504 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-11-17stop vclcanvas from ruining alpha of bitmaps in Skia modeLuboš Luňák
According to the comment and tdf#45219 vclcanvas deliberately forces alpha to be 1bpp because of poor performance. But that's not the case with Skia, alpha is always 8bpp there, so all the hack does it make animations look ugly and it also breaks caching capabilities of the Skia backend because the hack always generates a new bitmap. I don't know which VCL backend the original problem was related to, so at least disable the hack for Skia. Change-Id: I8a90c32dbe911cb79b617c0c447f3e9ced05f746 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125373 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-10-31add o3tl::span ctor from std::vectorLuboš Luňák
Makes code simpler, and std::span can be constructed from std::vector too. Change-Id: Iae26b53c52148c19d9068a63126a7393d098d654 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124507 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Tested-by: Jenkins
2021-10-30Another tools::Long->sal_Int32 in the DX arrayMike Kaganski
A leftover from commit bc413e15fae3672f580894a3cd7b077d533d8e6c Change-Id: Ibacdf71f608657a4488c84b88ef54fb52d3e8439 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124496 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-30tools::Long->sal_Int32 in the DX arraysNoel Grandin
Change-Id: I36ddc11b39763dc77086591fe9bb756195b4294f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124459 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-10-29pass DX array around using o3tl::span instead of pointerNoel Grandin
so we get bounds checking in debug mode Note that I cannot just pass around the std::vectors involved because there is a place in editeng which calls with a subset of a vector. Change-Id: I5088a139593c27bf9cbe5d843ab4b0048ac6d508 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124330 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-10-29Prepare for removal of non-const operator[] from Sequence in canvasMike Kaganski
Change-Id: Ifb96e496b0994b5fc66975b7aea0a60bcb4a3a03 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124345 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-15Simplify vector initialization in canvasJulien Nabet
Change-Id: Id359ec7fa58350f578f9da430c3b0536c6ff8a35 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123659 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-10-12loplugin:unusedmethodsNoel Grandin
Change-Id: Ifd3a1ccef68ebc4cd4e7785357e6a476f6669eb8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123456 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-10-11loplugin:moveparam in canvasNoel Grandin
Change-Id: I12538ca8c3578f37a4ef1e40640f5324bbdbb1d4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123371 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-10-01loplugin:constparamsNoel Grandin
Change-Id: I0d1ad95a9944c9077a1b9db11f2ae05f993c2b36 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122900 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-28vcl: rename OutDevState to StackChris Sherlock
I have moved the header file to include/vcl/rendercontext as this will eventually be part of the RenderContext split from OutputDevice. State and associated enums have also been moved to the vcl namespace. I have also moved ComplexTextLayoutFlags into the vcl::text namespace. Change-Id: I0abbf560e75b45a272854b267e948c240cd69091 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121524 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-08-28clang-tidy:readability-redundant-member-initNoel Grandin
Change-Id: I48e6fb31df732805423b89ed91b6e4363a69b668 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121150 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-18undo changes to TextAlignCaolán McNamara
revert commit 8689bd5490b473a7ffb149bbe5f7f0683f679c72 Author: Caolán McNamara <caolanm@redhat.com> Date: Thu Jul 29 20:49:29 2021 +0100 convert TextAlign to scoped enum lets leave this as it always was Change-Id: Id4d2a5644974cdd2b0ed6d361d5c52629674d057 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120626 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-08-17rtl::Static -> thread-safe static localNoel Grandin
Change-Id: I9f8fe250813f4f376dc46c6f3d7e25e90fdbb50e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120566 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-16Drop tools::Rectangle::getX/getY, which are just duplicates of Left/TopMike Kaganski
The change allowed to simplify many places where previously this API was used, to avoid inefficient calculations (e.g., moving rectangle keeping its size, and then immediately changing the size). Change-Id: Ica2dc594d91cae83e2c2740c1f4fb23f44998916 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120461 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-08-08use some forward declaresCaolán McNamara
Change-Id: If7f726e8dddb63c8a566f9aa208cd317213d5eba Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120166 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-08-03Consolidate on C++17 std::scoped_lock instead of std::lock_guardNoel Grandin
as in commit 9376f65a26240441bf9dd6ae1f69886dc9fa60fa Change-Id: I3ad9afd4d113582a214a4a4bc7eea55e38cd6ff9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119927 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-02convert #defines to OUStringLiteralNoel Grandin
mostly by doing $ git grep -l '#define.*\"' -- *.cxx | xargs perl -pi -e 's/^#define\s+(\w+)\s+(\".*\")/constexpr OUStringLiteral \1 = u\2;/g' Change-Id: Idface893449b0ef2a3c5254865a300585d752fbb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119669 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-30convert TextAlign to scoped enumCaolán McNamara
Change-Id: Id2c466eacb44f0ea6adba75a0ac0be8be8e7ed4c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119682 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-06-28loplugin:indentation improve checks for brace alignmentNoel Grandin
Change-Id: I333100fda7e181f68f36b03279b3fbb8cb768310 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117615 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-15fix big-endian codeNoel Grandin
after the transparency->alpha changes in ::Color Change-Id: Ifbac6c8f37f18e8acaef0602ef414ae39449ad3c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117209 Tested-by: René Engelhard <rene@debian.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-07Simplify Sequences initializations (canvas)Julien Nabet
Change-Id: I651858d71e378341205d6a785bd97f294664a439 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116737 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-05-31canvas : use std::mutex in CanvasFactoryArnaud Versini
Change-Id: Ic492f6b398ace3796d4b2cd45455d9ddec6cd728 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116416 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-26gbuild: Handle glxtest + vclmain usage via macrosJan-Marek Glogowski
Use a macro to do the same checks for all Executable with glxtest or vclmain usage. Both are static libraries, so every user has the same dependencies. Introduces: * gb_Executable_use_vclmain * gb_Executable_use_glxtest Change-Id: Ib80b4e7c6f5078d47ad8f1ec5708a7174415f705 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116145 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-05-24adapt oglcanvas::SpriteDeviceHelper::getDeviceHandleCaolán McNamara
to match the other implementations that return the OutputDevice* I tried enabling SpriteCanvas.OGL in officecfg/registry/data/org/openoffice/Office/Canvas.xcu with <node oor:name="com.sun.star.rendering.SpriteCanvas" oor:op="replace"> <prop oor:name="PreferredImplementations" oor:type="oor:string-list"> <value oor:separator=",">com.sun.star.comp.rendering.SpriteCanvas.DX9, - com.sun.star.comp.rendering.SpriteCanvas.Cairo, + com.sun.star.comp.rendering.SpriteCanvas.OGL, com.sun.star.comp.rendering.SpriteCanvas.VCL but it crashes before it gets very far and before it gets to this method. I tried in 7.1 and 7.0 but the same result so I can't tell if this fix is needed, but they surely should be the same as the others. Change-Id: I4f3715568eb0ec3a3bc57f6e6bdf158ff530ca5c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116061 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-05-19ImplPlayWithRenderer never checks its OutputDevice against nullptrCaolán McNamara
just pass a reference instead and spread that around to some similar cases Change-Id: Ifb2dee8c7bf02a9f01982b928c90666cbbdd84fe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115759 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
generated by cgit (git 2.34.1) at 2024-12-28 10:25:03 +0000