summaryrefslogtreecommitdiff
path: root/canvas/source/vcl
AgeCommit message (Collapse)Author
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>
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-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-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-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-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-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-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-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>
2021-04-26drop mask from BitmapExNoel Grandin
So that we have fewer cases to deal with when we transition to 32-bit bitmaps. (*) rename maMask to maAlphaMask, since now it is only being used for alpha duties. (*) drop mbAlpha and mbTransparent to simplify state management, the only thing we need to check for alpha is if maAlphaMask is non-empty. Change-Id: I06252e38e950e846a94b4c2ba8ea763be17801fe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111679 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-15tdf#141269 Incorrect transparency after roundtripCaolán McNamara
Revert "convert internal bitmap formats transparency->alpha" This reverts commit c181e510c5f5e74f1f6824b64637849aace9ae63. and later fix up of Revert "tdf#141504 qt5: ugly images" This reverts commit e7424ff25a724ea5bb54b2282d5c3cbf74c92053. a lot of places are still working int transparency values and not opacity Change-Id: I31342cdb76629acbaebfcdfa385407d3291fe06f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114150 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-04-02vcl: remove GetBitCount and GetColorCount from Bitmap{Ex}Tomaž Vajngerl
We can cast the PixelFormat enum to int for the same information and we can use the enum to reduce ambiguity when possible. Change-Id: I6ea648139465568cdeb12e5f5f75c7b609365bf4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113188 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-03-28drop operator bool and operator! from Bitmap and BitmapExNoel
IRC chat: <quikee[m]> noelgrandin: doesn't adding operator bool to Bitmap has the same problem as Graphic and the reason why you dropped that commit 7334034ae93b49fc93b5859a3c047a319d138282 "drop Graphic::operator bool" <noelgrandin> quikee[m], hmmm, good point <noelgrandin> maybe I should just drop both operator bool and operator! in favor of IsEmpty <quikee[m]> noelgrandin: I don't remember what the problem is I just remembered we dropped it Graphic :) sure, dropping everything for IsEmpty is probably the best Change-Id: Ieae289cda64f0b8d8fdecd5ea9e6f2bb874ff4cd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113163 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-03-13add PixelFormat enum that replaces bit count in Bitmap/BitmapExTomaž Vajngerl
Bit count for the image is a numeric value (sal_uInt16) but only a handful of values make sense - namely 1,4,8,24 and 32. This replaces the numeric value with an enum, which only accepts those values and checks the correct values are used at compile time. Change-Id: I0fc137c62bce3b0d021f05019a1648da628521bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112408 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-02-24add additional 0-1 alpha argument to DrawTransformedBitmap()Luboš Luňák
This allows the VCL backends the apply the extra alpha transformation as it sees fit, rather than it being done manually elsewhere (and even if the backend doesn't implement it, at least do it in one place in the function). With the document from tdf#136223, going from slide 2 to slide 3, this easily saves 10-30% of CPU cycles. As an additional bonus, using AlphaMask::BlendWith() rather than AlphaMask::Replace() makes edges of shapes noticeably more smooth. Change-Id: I036dc9b887d6def0c7cdad3982becabdc7cd5206 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111247 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-02-24simply use drawTransformedBitmap()Luboš Luňák
At least with Skia this is faster than GraphicObject trying to handle it manually, even in raster mode. Change-Id: If77d108751f5621878d4ea87a996c2ea0253d111 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111246 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-02-23convert internal bitmap formats transparency->alphaNoel Grandin
Image formats and graphics APIs use alpha, not transparency, so change our internal formats and data structures to work directly with alpha, so we don't need to modify data before we push it to graphics APIs. Change-Id: I537f77f79e83876be11d787901df42710d190842 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108919 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-02-22loplugin:refcounting in canvasNoel
Change-Id: I77e4d29b2911bb86c383afbf977d241eaa8cd341 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111307 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-02-17loplugin:referencecasting in canvasNoel
Change-Id: Ic802d6593db053bb31c3463e67b63399b5f26d67 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111001 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-02-09simply use DrawTransformedBitmapEx()Luboš Luňák
And leave the work to the function instead of trying to handle it manually. Change-Id: Ia1ede2378d461a57e5c338ab5cabe908c320b2b4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110599 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-01-13transparency->alpha in GraphicAttrNoel
Change-Id: I1fe9311871724ff8b7b8960f5dba6e890198565c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109211 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-12transparency->alpha in tools::ColorNoel
this just changes the Get/Set methods, the constructor and internal representation of Color is not changed. Change-Id: Idb6e07cc08bbaa5bd55b6bd4b585e648aef507b6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109074 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-24vcl: move access functions into appropriate bitmap access filesChris Sherlock
Split class functions into BitmapInfoAccess.cxx, BitmapReadAccess.cxx and BitmapWriteAccess.cxx Split header files into BitmapInfoAccess.hxx and BitmapReadAccess.hxx Change-Id: I7dcbe1d26c5b64d297658a6b809c93d7ad7f053d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108039 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-12-04Revert "tdf#118107 canvas opengl: avoid assertion failure with negative widths"Luboš Luňák
I fixed the assert with 4eb816de71f1310a3a5d9803f7355849e6273439 (and follow-up commits), so this is no longer needed. This reverts commit 76b43425d764fbc9bf4dac52054b1d94344f26b0. Change-Id: I85dec14cc8858b7168532661de9ca77c31802a62 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106962 Tested-by: Luboš Luňák <l.lunak@collabora.com> Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-11-17try to use directly VCL's DrawGradient() in vclcanvas (tdf#136523)Luboš Luňák
VCL implementations may have an optimized implementation, and with Skia decomposing to polygons also causes drawing problems. Change-Id: Ib1e317c627f01a43b77b9a8ee2335f4e319c37e2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106016 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-11-16Instead of labs, use overloaded absStephan Bergmann
...more likely to pick an appropriate version for the involved integer types, esp. after the recent long -> tools::Long changes Change-Id: Ia91259ca35aaf74b0e907de6831fc926f30057f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105949 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-06tdf#42949 Fix new IWYU warnings in directories c*Gabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: Iac1e7802dbe1efa01c2befdd10406231788d4fc1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105315 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-11-01Transport Pixmap from GetNativeSurfaceHandle via css::uno::Any as sal_Int64Stephan Bergmann
The values returned from GetNativeSurfaceHandle are only used in cairocanvas::CanvasBitmap::getFastPropertyValue (canvas/source/cairo/cairo_canvasbitmap.cxx), whose consumers in turn are (at least the ones I could identify): * OGLTransitionerImpl::setSlides (slideshow/source/engine/opengl/TransitionerImpl.cxx), passing the values on to X11SalObject::SetLeaveEnterBackgrounds, which extracts the Pixmap value to pass it on to XSetWindowBackgroundPixmap. * X11SalBitmap::Create (vcl/unx/generic/gdi/salbmp.cxx), which extracts the Pixmap value to pass it on to X11SalBitmap::ImplCreateFromDrawable (as a Drawable) and to XFreePixmap. While Pixmap XIDs are apparently 32-bit in the X11 protocol, see e.g. <https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html>, Xlib and the underlying /usr/include/X11/Xdefs.h appear to be somewhat confused whether the typedef for XID should be unsigned long (presumably stemming from times when long was universally 32-bit) or CARD32, see e.g. <https://gitlab.freedesktop.org /xorg/proto/xorgproto/-/blob/master/include/X11/Xdefs.h>. So conservatively stick to a 64-bit type here, even if it should only ever contain 32-bit values. Change-Id: I26c3a2ff74cef092042a6e3648cd9a6f4a9e3aac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105144 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-28convert some more long -> tools::LongNoel
Change-Id: Ide9811c1a7582454b3fcf655b70ea106ed56509a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104914 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-21use tools::Long in basegfx..chart2Noel
Change-Id: Ide4014348d51f0b5f59e1e91b8d41c7748853254 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104608 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-21new tools::Degree10 strong typedefNoel Grandin
partly to flush some use of "long" out the codebase, but also to make it obvious which units are being used for angle values. Change-Id: I1dc22494ca42c4677a63f685d5903f2b89886dc2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104548 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-20do not disable AA in vclcanvas if Skia is usedLuboš Luňák
Perhaps AA may not look good with GDI or Xlib VCL, but with Skia it is fine (and if it's not, I'll fix it). Also avoid the repeated copy&paste. Change-Id: I7aa60ae1e1c8a2ab4fa93d08ab0dfeb23c9c2cb7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104437 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-10-01loplugin:reducevarscope in canvas,chart2Noel
Change-Id: I6c73e609cc8ce0ed9cf0f5a6b68c6e299bf26a44 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103761 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-29make vclcanvas try directly VCL for drawing stroked polygon (tdf#136933)Luboš Luňák
There's no point in trying to do all the stroking stuff manually if the VCL function can do it and better/faster. Change-Id: I9949637e2504d9b5d10ac77fbd5bd1f491ea6eee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103313 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-29Revert "don't split polypolygon in canvas if not needed" (tdf#136933)Luboš Luňák
With the doc from tdf#136933 basegfx::utils::createNonzeroConform() gets called with huge polygons, which is very expensive. Revert this, I'll fix the Skia problem by directly trying to draw the stroked polygon with VCL. This reverts commit b0788ff11481568b413ff6e4c3ea4871984af974. Change-Id: I19b3435811b6ea38d83bea08056802aac76bf45c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103312 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
generated by cgit (git 2.34.1) at 2025-01-16 03:57:15 +0000