summaryrefslogtreecommitdiff
path: root/vcl/inc/headless
AgeCommit message (Collapse)Author
2020-05-05fix line width in DrawPolyLine() with matrix (tdf#132498)Luboš Luňák
For backends that do the object-to-device coordinates transformation directly, it's necessary to also convert the size of line width. But simply multiplying it with the matrix can also rotate the line width "vector", making it e.g. negative. So don't use just the X coordinate, use vector length for the transformation, which is ok. In fact it doesn't even make sense to treat width as a vector, because a width simply is not a vector (and for this reason it's also not actually used). Change-Id: I1241c9cb29155df105170d568a879ebc32b11a5f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93203 Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Tested-by: Jenkins
2020-04-03fix android buildNoel Grandin
after commit d9e478330243cbd120f2de33df3333fec2ef9217 Date: Fri Apr 3 10:16:22 2020 +0200 loplugin:finalclasses in xmlsecurity..UnoControls Change-Id: Ia6566d33b4a2d6c81e009f8baebce8367bba2486 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91641 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Reviewed-by: Rene Engelhard <rene@debian.org> Tested-by: Rene Engelhard <rene@debian.org> Tested-by: Jenkins
2020-04-03loplugin:finalclasses in xmlsecurity..UnoControlsNoel Grandin
Change-Id: I8e942bf37c9173a01bef6e1403ca21f579e7f608 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91612 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-03-16Revert "loplugin:constfields in vcl"Noel Grandin
This reverts commit 59887868da3499c68d5f259cfa48178354397448. Change-Id: I0f3f6a7680c78103a559a0f881badc8211b97ace Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90544 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-02-21tdf#130768 speedup huge pixel graphics CairoArmin Le Grand (Collabora)
For more information/documentation please refer to the bugzilla task Fixed a crash in CppunitTest_desktop_lib which led to a missing test of mpGraphics in OutputDevice::DrawTransformedBitmapEx. Other public methods test that and one of the goals of the cange was to use that method more often, so this may have never been detected before Change-Id: I10e57bd05db0c8cf868ff98d63f5af3d116a3015 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89230 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2020-02-07tdf#130478 Enhance Dashed line drawing on all systemsArmin Le Grand (Collabora)
For more info and explanation including state of process information and discussion(s) see task please. Adding corrections for gerrit build Change-Id: Ie10fb8093a86459dee80db5ab4355b47e46c1f8c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88130 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2019-11-28Blind additional fix of the Android TB build errorJan-Marek Glogowski
Change-Id: I8dd4beedb5d1d5a555af2bb9c513878c0651e3d8
2019-11-28Blind fix of the Android TB build errorJan-Marek Glogowski
Change-Id: I02f8eaff7e44197743c071a1b4c90b314c0e6b4c
2019-11-27loplugin:finalclasses in vclNoel Grandin
Change-Id: If22569a1b7d53fc1b5b87f7ec7d262ebb260e798 Reviewed-on: https://gerrit.libreoffice.org/83933 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-11-27android: Introduce --enable-android-lok configure switch to fix RGB vs. BGR.Jan Holesovsky
This indicates that the build targets the Online-based Android app, for which we need to avoid various tweaks that are needed for the 'old' Android app present in the android/ subdir of core.git. In particular, the switch used in this patch fixes a RGBA vs. BGRA confusion that caused yellow <-> cyan switch in the Online-based Android app. Change-Id: I5f394868f51ce87013677834cfafb967b9bb333e Reviewed-on: https://gerrit.libreoffice.org/83342 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Jan Holesovsky <kendy@collabora.com> (cherry picked from commit 49002a143a4534df5f6139e07fefd06174621c59) Reviewed-on: https://gerrit.libreoffice.org/83718 Tested-by: Jenkins
2019-11-27extend vcl backendtest to more backendsLuboš Luňák
At least the KF5/Qt5 VCL plugins passes fine. Change-Id: I033ddf6ae9cc663729ca459cdc514dc0fa51ddc2
2019-11-22make some classes module-privateNoel Grandin
Change-Id: If7303a082e06f6937fca911c578a40475546cda2 Reviewed-on: https://gerrit.libreoffice.org/83442 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-11-19Rename GlyphCache to FreetypeManagerJan-Marek Glogowski
And while at it remove the unneeded getPlatformGlyphCache abstraction. Change-Id: Id5cad751eda9e6bf177dfb4816280d7c5af7066a Reviewed-on: https://gerrit.libreoffice.org/83125 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-11-08widget theme: Gradient support when drawing widgetsTomaž Vajngerl
Change-Id: I29239348e36e4963d9708a22ac649b2b1d68bf02 Reviewed-on: https://gerrit.libreoffice.org/82207 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2019-11-05make some classes module-privateNoel Grandin
Change-Id: Ice9a57eedb166672dbdfae6da2a172ab77566a19 Reviewed-on: https://gerrit.libreoffice.org/81983 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-06SystemEnvData::nSize is no longer read and can be removedStephan Bergmann
...since 5926b22b5dc33490d23d594b129eb8a70b94ffb0 "The SystemEnvData passed into the canvas factories appears to be unused". (And the user-provided SvpSalObject ctor can be removed, at which point the use in SvpSalInstance::CreateObject should be written without "()" to avoid loplugin:subtlezeroinit. Change-Id: I4392fa2d697b29c814d7b577a7b1f8c984c05e70 Reviewed-on: https://gerrit.libreoffice.org/80298 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-04tdf#127529 vertical text not drawn in slideshow canvasCaolán McNamara
because the canvas text drawing impl falls back to using an OutputDevice view of the canvas to use the vcl text drawing apis to achieve vertical text To get an OutputDevice view of the canvas there is a specific VirtualDevice ctor available to create a VirtualDevice that, unlike the normal case, doesn't have its own specific backing buffer, but instead draws to the underlying target provided via the SystemGraphicsData arg The svp/gtk impl missed that understanding and provided an ordinary VirtualDevice with its own backing buffer, not a VirtualDevice that would draw to the expected target surface of the canvas. So the vertical text was drawn to a different surface than the intended one, and was just discarded. The cairo use in the canvas long precedes the use of cairo in vcl itself. Seeing as text is now rendered with cairo in all cases where the canvas uses cairo its probably now pointless for canvas to have its own text rendering path. Change-Id: Ie3b0a43ca2b746cbfe25e2d0415315b3d5403cd2 Reviewed-on: https://gerrit.libreoffice.org/80162 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-10-03factor out the actual surface creationCaolán McNamara
Change-Id: I77520b67b988f583dfd277e69d8181b9acdbd904 Reviewed-on: https://gerrit.libreoffice.org/80153 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-09-06use unique_ptr in CreatePrintGraphicsNoel Grandin
Change-Id: Ib9ca0173f3b5bb090ae71f8622fef717a47e8a2b Reviewed-on: https://gerrit.libreoffice.org/78704 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-23loplugin:returnconstval in vclNoel Grandin
Change-Id: Id4a0b460ba3c43e80b80ae6e2da9e40a6753e14c Reviewed-on: https://gerrit.libreoffice.org/77965 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-06-18VCL cleanup WidgetDrawInterfaceJan-Marek Glogowski
I don't understand why WidgetDrawInterface, which is basically a copy of the SalGraphics native controls interface, duplicated it, instead of cleaning things up. The whole commit message of commit 8fcfa3853a81, which added this code, is just: "custom widgets: Custom Widget Themes". That's it. So this patch does, what the original one skipped: replacing the SalGraphics interface with the WidgetDrawInterface. One result is the addition of handleDamage to SalGraphics to correctly handle the damage done by a custom widget theme to the underlying SalGraphics implementation. Change-Id: I5fda1a64b28e6560fb3c62e02b6dcda827f698e2 Reviewed-on: https://gerrit.libreoffice.org/74118 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-06-13tdf#42949 Fix IWYU warnings in vcl/inc/*Gabor Kelemen
Platform-specific subdirs are left alone: android, ios, osx, quartz, win Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: Icbb906b7fbc960240c73c56d3dae2a78b06a0f53 Reviewed-on: https://gerrit.libreoffice.org/73754 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-06-08tdf#125673 KDE5 implement a KDE5SalVirtualDeviceJan-Marek Glogowski
We just need AcquireGraphics() to return a KDE5Graphics. Otherwise the BufferDevice's SVP will use a SvpSalGraphics instead of the KDE5Graphics, which knows about Qt's theming. Change-Id: I0ea646df260f2067d61c753f03dee01a003f382a Reviewed-on: https://gerrit.libreoffice.org/73673 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-05-16Using the m_FeedbackFDs is now apparently necessary also on iOSTor Lillqvist
The below commit message is relevant for the behaviour fixed by this change in the Collabora branch cp-6.0 (or core) and collabora-online-4 (of online). The behaviour here in master is broken in different ways, though, and I am not entirely sure whether this change fixes anything here. But let's apply it here, too, for consistency. Until recently we had managed without them on iOS, but that changed with the recent "Unipoll" work, I think. (Without this change, the iOS app now runs into assertion failures early on. But note that this change is not enough to make it work fully again.) Change-Id: I09d25326ba73ce897da5c91f30530f5b3d5fd272
2019-05-03tdf#120585: use applyColor and make it transparency-awareKatarina Behrens
An overloaded drawPolyPolygon for zero transparency case used to exist and it used applyColor to fill cairo path. It was removed by commit 7034311dce663c895577267110baadbec312d491 and the new transparency-aware drawPolyPolygon missed cairo_set_operator call that is present in applyColor. This works OK most of the time but breaks sometimes when no transparency (~no antialiasing) is involved. To fix that add transparency argument to applyColor and use it where applicable Change-Id: Ib1b077e38e7f5d30778434d45be67284407a7d16 Reviewed-on: https://gerrit.libreoffice.org/71700 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-04-23Unipoll: add LibreOfficeKit API for polling, and an option to use it.Ashod Nakashian
Change-Id: Iee7556ee52541ddbf1ef8f31e1ed4697f805a2ac Reviewed-on: https://gerrit.libreoffice.org/70898 Tested-by: Jenkins Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
2019-04-04Resolves: tdf#124219 check at runtime for availability of cairo functionsCaolán McNamara
Change-Id: I0ab3055760d8be690bdfff560212db368a0fa261 Reviewed-on: https://gerrit.libreoffice.org/70240 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-04-03Support for native 32bit Bitmap in VCL and SVP (cairo) backendTomaž Vajngerl
This adds basic support for 32bit bitmaps for the SVP backend. For other backends the support is disabled for now as we need to add it for each backend separately and enable support. When this patch is applied it is possible to a Bitmap with bit count 32, but currently no input filter uses this with the exception of the new PngImageReader(libpng based), which is used only for the icons. For a general support more things need to be implemented and tested: - conversion back and fourth between 32-bit and 24-bit + 8bit alpha (or other supported pairs) - 'raw' export of the bitmap needs to be handeled properly (like in SVM import/export) so it creates the correct image. - input filters need to be checked and converted if this is necessary - look for possible bugs when drawing transparent bitmaps - check of UNO API Change-Id: I7a7be0e6134dfdd9a7aeaef897131bb6e710ae7e Reviewed-on: https://gerrit.libreoffice.org/69289 Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Tested-by: Tomaž Vajngerl <quikee@gmail.com>
2019-02-27convert more Start timer methods from sal_uLong->sal_uInt64Noel Grandin
Change-Id: I1ed43bab00a5bc456032410ccf32b3fd64cc970c Reviewed-on: https://gerrit.libreoffice.org/68419 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-02-26fix android buildNoel Grandin
after commit 589ce33041df5ca1c3f6d914d5d33d0fffb69f8f Date: Mon Feb 25 14:38:21 2019 +0200 sal_uIntPtr->sal_uInt64 in SalTimer::Start Change-Id: I0091ac4750dfb2ca8a3f4b5a544f7ec4f0ee0957
2019-02-26sal_uIntPtr->sal_uInt32 inSalClipRegion::BeginSetClipRegionNoel Grandin
sal_uInt32 seems reasonable given that this is the number of rectanges in an image. And then convert all of the other BeginSetClipRegion methods to use sal_uInt32 too. Change-Id: I85a712ec823662ac30f3859051e2b974fb99775e Reviewed-on: https://gerrit.libreoffice.org/68343 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-02-26sal_uLong->sal_uInt32 in drawEPSNoel Grandin
Change-Id: I58beedfee1a55df971e778ba2aa3b6989ba53663 Reviewed-on: https://gerrit.libreoffice.org/68341 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-01-25Change SalGraphics::GetTextLayout definitionJan-Marek Glogowski
* drop the unused ImplLayoutArgs argument * return a std::unique_ptr<GenericSalLayout> Change-Id: I150a2a46f67f1ffbbd3ba0ffa68f5bffb30206c8 Reviewed-on: https://gerrit.libreoffice.org/66884 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-01-23loplugin:constparams in vclNoel Grandin
Change-Id: Icf1a952fbe190fd6c4efd89364136aa2b48050e3 Reviewed-on: https://gerrit.libreoffice.org/66767 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-12-05tdf#121719: Revert fix for tdf#96971Xisco Fauli
it's still used on Mac. Revert it until XOL is removed This reverts 258301879bcd20397c38bbd522dea2c923bd9fc2 Change-Id: I06548a590f370618ad640724a1b9c59a3faceec2 Reviewed-on: https://gerrit.libreoffice.org/64582 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-11-09custom widgets: Fix various warnings.Jan Holesovsky
Change-Id: I5d657fa4d6f63b93ad3775a5641d08c6e0f3a615
2018-11-09LOK: custom widgets: reduce theme plugin API surfaceAshod Nakashian
Change-Id: I89dcf5a102be19fd1bc314a89538a121522f4a43
2018-11-09LOK: custom themes: isolate LO internals headers from theme pluginAshod Nakashian
Change-Id: Ic189aecf092b9cffd800e410d2d6e88016c43052
2018-11-09custom widgets: setup style setting in the widget libraryTomaž Vajngerl
Some theme colors are set using the style settings, which are implemented by each backend to correspond to the system theme. For custom widgets these need to also be set by the library itself. This commit adds the ground work and sets some of the colors for windows backgrounds. Change-Id: Ia65b1605b2b7bef7f01ff1feff2e7470479e626a
2018-11-09Support drawing custom widgets in headless backendTomaž Vajngerl
..and fallback the headless dawing also in gtk3 where needed Change-Id: Ic5da8fa7a04089342db8e2f334ced69691a15217
2018-11-09custom widgets: Custom Widget ThemesTomaž Vajngerl
Change-Id: I7ec57d18fe99f906aeb6dbb40d0d30c2ac8b51c4
2018-11-08Bin some leftover and actually unnecessary iOS crack in vclTor Lillqvist
We don't need the '#define SvpSalGraphics AquaSalGraphics' in vcl/inc/headless/svpgdi.hxx. The actual AquaSalGraphics we use for iOS is in vcl/inc/quartz/salgdi.h. I don't remember the details of the convoluted history behind this. Change-Id: Ie56c3c93acf7ad89e10a05e75aa4ca7fd596ba98 Reviewed-on: https://gerrit.libreoffice.org/63098 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2018-11-01tdf#120777 KDE5: Dialogs get blank when they are resizedAleksei Nikiforov
On window resize qt5 only redraws changed parts of widgets. If resize is minor (i.e. height has increased by 1 pixel, for example), qt5 may consider most parts of widget not changed and skip redrawing them and redraw only certain widget elements. But if cairo is used for drawing, on resize previously drawed image of widget is discarded and new one of different size is created. New image is empty, but qt5 doesn't issue redraw for whole widget. To mitigate this issue, data from old image of widget should be copied over to image of new widget, qt5 will redraw it partially or fully if necessary. Change-Id: Id950074efece9072bbfc002dfcb6ead813d5aeff Reviewed-on: https://gerrit.libreoffice.org/62698 Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> Tested-by: Jenkins
2018-11-01loplugin:useuniqueptr in SalFrame::PostEventNoel Grandin
Change-Id: Ib066b1d6df90f330f2f93ec639bd7bc59a08c024 Reviewed-on: https://gerrit.libreoffice.org/62507 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-10-31loplugin:useuniqueptr in DeletePrinterQueueInfoNoel Grandin
Change-Id: Ia124a4af642e449dc05f5bae2d5ca766bd67bd68 Reviewed-on: https://gerrit.libreoffice.org/62388 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-10-30Move SalGraphics glyph functions into FontInstanceJan-Marek Glogowski
As we already rely on the GlyphItem's font instance, consequently this removes the SalGraphics GlyphItem based functions. Also unifies the glyph bound rect cache handling. An interesting aspect is the rotated glyph bounding box handling moved from CairoTextRender to FreetypeFont. It doesn't look like an implementation detail for Cairo, so it may have been a bug. Change-Id: I81bbb5d8ee98fb77a1eee05568c456f9e4553023 Reviewed-on: https://gerrit.libreoffice.org/62503 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2018-10-30m_FeedbackFDs is unused on iOSTor Lillqvist
I wonder why we have that iOS ifdef in SvpSalInstance::Wakeup()? Elsewhere in this file we do compile code that uses those same fields for iOS, too. Change-Id: Ib801ea81fafcf2296181874018c1df2ceef144a1
2018-10-08No cairo used on iOSTor Lillqvist
Change-Id: I2fc713be404e68ea2fd0db43d0e93dfd62279da8
2018-09-14loplugin:constfields in vclNoel Grandin
Change-Id: I1072642be4fdfa720e61f2d7bad3c2701eb81610 Reviewed-on: https://gerrit.libreoffice.org/60430 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-09-13Support buffering SystemDependent GraphicData (II)Armin Le Grand
In this step I have changed all calls that use a B2DPolyPolygon and do filled graphics, added support for providing needed transformation which will -if supported- be used. Added buffering of SystemDependentData at B2DPolyPolygon for that purpose, see comments describing the current possibilities in the Gdiplus implementation. Moved lifetime creation/cleanup of SystemDependentDataManager to ImplSVData due to cleanup problems in the clang build Tried to use a std::unique_ptr to hold the instance of a SystemDependentDataBuffer at ImplSVData and cleanup inside DeInitVCL() right before ::ImplDeInitScheduler. This works in principle, but scheduler shutdown triggers ProcessEventsToIdle which leads to repaints and re-creates the buffer. Will now do exactly as was done with GdiPlusBuffer before, a simple local static incarnation and a call to SetStatic() in constructor Splitted SystemDependentDataBuffer and Timer due to different LifeTimes. Timer needs to be destructed earlier than SystemDependentDataBuffer, before Scheduler::ImplDeInitScheduler() is called from DeInitVCL() Change-Id: I2134e4346a183a4cee1be3428c51541cc8867c11 Reviewed-on: https://gerrit.libreoffice.org/60102 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
generated by cgit (git 2.34.1) at 2025-02-11 05:38:31 +0000