summaryrefslogtreecommitdiff
path: root/canvas
AgeCommit message (Collapse)Author
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>
2021-05-18Drop assert checking address of reference is not nullptrMichael Weghorn
It was introduced in commit 9090dc1f3b27195f5defd35586ac79357992be21 Date: Mon Jan 18 18:27:19 2021 +0200 split OutputDevice from Window and caused my GCC 10 '--enable-werror' build to fail with In file included from /usr/include/c++/10/cassert:44, from .../include/tools/ref.hxx:23, from .../include/vcl/outdev.hxx:24, from .../canvas/source/vcl/impltools.hxx:25, from .../canvas/source/vcl/canvas.hxx:39, from .../canvas/source/vcl/canvas.cxx:22: .../canvas/source/vcl/outdevholder.hxx: In constructor ‘vclcanvas::OutDevHolder::OutDevHolder(OutputDevice&)’: .../canvas/source/vcl/outdevholder.hxx:38:16: error: the compiler can assume that the address of ‘rOutDev’ will never be NULL [-Werror=address] 38 | assert(&rOutDev); | ^~~~~~~~ cc1plus: all warnings being treated as errors make[1]: *** [.../solenv/gbuild/LinkTarget.mk:301: /home/michi/development/git/libreoffice/workdir/CxxObject/canvas/source/vcl/canvas.o] Error 1 make[1]: *** Waiting for unfinished jobs.... In file included from .../include/comphelper/solarmutex.hxx:25, from .../include/vcl/svapp.hxx:29, from .../canvas/source/vcl/impltools.hxx:24, from .../canvas/source/vcl/spritecanvas.hxx:44, from .../canvas/source/vcl/spritecanvas.cxx:28: .../canvas/source/vcl/outdevholder.hxx: In constructor ‘vclcanvas::OutDevHolder::OutDevHolder(OutputDevice&)’: .../canvas/source/vcl/outdevholder.hxx:38:16: error: the compiler can assume that the address of ‘rOutDev’ will never be NULL [-Werror=address] 38 | assert(&rOutDev); Change-Id: I9e8ef7e91dba847f4894124348f13755fc620fac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115737 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2021-05-17split OutputDevice from WindowNoel Grandin
as part of a longer-term goal of doing our widget rendering only inside a top-level render- context. I moved all of the OutputDevice-related code that existed in vcl::Window into a new subclass of OutputDevice called WindowOutputDevice. Notes for further work (*) not sure why we are getting an 1x1 surface in SvpSalGraphics::releaseCairoContext, but to fix it I clamp the size there (*) might have to dump VCLXDevice, and move it's code down into VCLXWindow and VCLXVirtualDevice (*) can we remove use of VCLXDevice in other places, in favour of just talking to the VCL code? Change-Id: I105946377f5322677d6f7d0c1c23847178a720b6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113204 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-14Directly initialize vectors in ogl_spritedevicehelper.cxxJulien Nabet
since we've got all the information from the beginning. static_cast were needed to avoid this kind of error: /home/julien/lo/libreoffice/canvas/source/opengl/ogl_spritedevicehelper.cxx:305:36: error: non-constant-expression cannot be narrowed from type 'sal_uInt32' (aka 'unsigned int') to 'double' in initializer list [-Wc++11-narrowing] mpTextureCache->getCacheMissCount(), mpTextureCache->getCacheHitCount() } ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/julien/lo/libreoffice/canvas/source/opengl/ogl_spritedevicehelper.cxx:305:36: note: insert an explicit cast to silence this issue mpTextureCache->getCacheMissCount(), mpTextureCache->getCacheHitCount() } ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ static_cast<double>( ) Change-Id: If2705251cc4a246c2b8cb0bf873d413b3c572880 Change-Id: Ie1ce45cb6518fe97442ec5f3f05d34bae586b417 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115585 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-05-12fix leak in canvas testNoel Grandin
Change-Id: I01d52e67711b0201bbabb8c36e990f494466ae55 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115499 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-07set also dashing cap style for directx canvas (tdf#136957)Luboš Luňák
Change-Id: I7022ffba519faad5a333d7ef6eabf1ba5f0ae3bd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115232 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-05-06a unittest for my cairocanvas fix for tdf#134053Luboš Luňák
Note that even though the fix is for cairocanvas, the unittest currently really checks only vclcanvas, because tests for cairocanvas do not work. Change-Id: I2c34822126c93460971c34932d5bdf3fe2d698b5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115146 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-05-06make it possible to write canvas unittestsLuboš Luňák
One of the problems is that canvas apparently works only with windows, but tests obviously need an offscreen surface. This patch moves Window::GetCanvas() to OutputDevice, and makes vclcanvas capable of working with OutputDevice classes that are not windows. Other canvas implementations still don't work, but presumably at least cairocanvas could be fixed too. This commit adds a "simple" test that just draws a line and tries to verify it's been drawn properly. Adding another test should be a matter of basing it on this existing one, and then copy&pasting the complicated UNO way of drawing using canvas from somewhere, such as canvas/workben/canvasdemo.cxx. Change-Id: I42db12b09433763cd31c3dd497c10157424b8598 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115117 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-05-05scale stroked line properly in cairocanvasLuboš Luňák
- Line width should be scaled by the scaled vector, not just its X component (see VclMetafileProcessor2D::getTransformedLineWidth()). - Lenths of dashes should not be scaled by the scaled line width, but by the scaling. Testcase document sd/qa/unit/data/pptx/tdf134053_dashdot.pptx . Change-Id: I4116f82e91620f5612f5e4e187468508f683b93e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115147 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-05-04messing with UNOMINMAX no longer seems to be necessaryNoel Grandin
and it sometimes causes trouble when including o3tl/strong_int.hxx Change-Id: I2957dc5c0159e1a9ab61681953023f6850de0125 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115098 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-04Use sal::systools::COMReference and drop dxcanvas::COMReferenceMike Kaganski
Change-Id: I352147dd86d8ba73da1706c42c885bef0f11b2cd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115071 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-05-03vcl: remove MetricVectorChris Sherlock
Change-Id: Ib700887ca79f423c65dfb75eea36bbfd808fa172 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114976 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-04-29remove support for BITMASK in vcl backendsNoel Grandin
Rather use a proper alpha channel if we need transparency. This is another small step towards merged alpha in our vcl layer. I suspect the intent in a lot of this code was to save memory. Which have been a thing way back then, but these days our backends mostly end up doing a copy-and-convert to a real alpha channel anyway, so the existing code is actually now a pessimisation. Change-Id: I4a2bcbb2f76b841f05bc00580f364492829c69de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114808 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit (git 2.34.1) at 2025-01-13 13:10:35 +0000