summaryrefslogtreecommitdiff
path: root/vcl/inc/salgdi.hxx
AgeCommit message (Collapse)Author
2021-12-11explain the intent of HasDrawTransformedBitmap() betterLuboš Luňák
Change-Id: I32d6cfb7358dae25109de4db3332797763abc7d8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126506 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@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-10-08vcl: test PhysicalFontCollection and move to vcl::font namespaceChris Sherlock
- tested PhysicalFontCollection, noted odd behaviour with search names and normalization - moved PhysicalFontCollection.hxx to vcl/inc/font - moved PhysicalFontCollection into vcl::font namespace Note that I needed to regenerate the pch file otherwise errors were generated. Change-Id: Ifa0c7b871c40687bd15002565d2f7a3e408218f8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122036 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-05vcl: test PhysicalFontFace and move to vcl::font namespaceChris Sherlock
- moved PhysicalFontFace.hxx to vcl/inc/font - added PhysicalFontFace to vcl::font namespace - had to regenerate precompiled_vcl.hxx - tested PhysicalFontFace, with some extensive tests for IsBetterMatch() Change-Id: I860022ac244f8a827f6f9cb7ed9018c5d9c328cb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121970 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-09-27vcl: move FontSelectPattern to own file and into vcl::font namespaceChris Sherlock
Change-Id: I2f01a8e67c52ece9b434777203aa9fbc9ac8be02 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122613 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2021-09-21vcl: add sal/config.h in preparation for patchChris Sherlock
The convention is that we need to add sal/config.h to the start of files. This patch is created in preparation of a patch I have queued to test and move PhysicalFontFace to vcl::font namespace. Change-Id: I15dd24d7f01e077d407ac192a0413d796517eb72 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122228 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-09-20tdf#124176 - Use pragma once instead of include guardsChris Sherlock
This patch is created in preparation of a patch I have queued to test and move PhysicalFontFace to vcl::font namespace. Change-Id: I805a8bd1fa881fc4bc6d2f26f1051b9247587701 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122226 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-09-06vcl: move ImplLayoutArgs to own header and source filesChris Sherlock
Add unit tests for ImplLayoutArgs. Also add to the vcl::text namespace. Change-Id: I9fa0943548be8ca17ea3dac104e9cb609337a70e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121209 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-07vcl: move graphic handling into Qt5GraphicsBackendTomaž Vajngerl
This is an effort to make SalGraphicsImpl mandatory for all backends. This introduces Qt5GraphicsBackend: a subclass of SalGraphicsImpl, which now handles graphic rendering. Change-Id: I42aece59d0c692ca1dd33e30f31c5bcceab02008 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113734 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-04-07vcl: class to automatically delegate calls to SalGraphicImplTomaž Vajngerl
A class for SalGraphic backends that delegates all the graphic drawing calls to SalGraphicImpl. Use this for GenPspGraphics. Change-Id: I0461259802732e9107d9011608530f1ffe2891ed Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113733 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-02-24actually prefer DrawTransformedBitmap() if it's known to be fastLuboš Luňák
This partially reverts the logic of change 9d89d98d3349502b56d, which always made DrawTransformedBitmap() get changed to DrawBitmapEx if only translation+scaling was involved. But since that one may call BitmapEx::Mirror() that'll do pixel-shuffling, trust the DrawTransformedBitmap() implementation to do the right and efficient thing if it says so. Change-Id: If25b3d189ddd46b235e122e5e8d6f8079ec09f7f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111248 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.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>
2020-12-15DrawGradient variant only called by FileDefinitionWidgetDrawCaolán McNamara
which doesn't do any mirroring on any of its drawing calls. Change-Id: I4f531ee01147b34f36a6d4235f3340bd1a8e62ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107769 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-15tdf#138936 gradient missing under RTL from writer comment marginsCaolán McNamara
Change-Id: I57533f033f9528b7c89162967b392eb5abb4d76a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107750 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-08remove more no longer needed OpenGL-related codeLuboš Luňák
Change-Id: If7f47cf6dad860e4f8eab68931b72a38a7eda136 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107362 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-12-07remove OpenGL VCL backend codeLuboš Luňák
It is by now practically unmaintained, even bugreports in bugzilla have been already closed for it. AFAICT this used to be really used only on Windows, where it's no longer the default. There's still some OpenGL code left, because there are still two other places that use OpenGL. One is OpenGL slideshows, which reuse some of the base OpenGL code (and I've checked they still work even after this removal). Second one is OpenGL canvas, which it seems has never been finished or enabled (or so it most probably should be dumped too). Change-Id: I7ea5aef77ec252eb8e712d167db591209be84a13 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107290 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-12-01DrawPolyLine/DrawPolyPolygon never called with null OutputDevice*Caolán McNamara
so we can remove some redundant nullptr checks, maybe making this a tiny less confusing Change-Id: Icba4ea1edd5b4883a294f52e0facaab631d94aed Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106860 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-11-30FileDefinitionWidgetDraw never provides OutputDevice*s for RTL mirroringCaolán McNamara
I'm not certain if the lack of an OutputDevice* to allow mirroring the drawing in a RTL environment is deliberate or not, but it seems plausible that is what we want here and that we are already mirrored by the time we get here, so let FileDefinitionWidgetDraw call the underlying post-mirror stage drawing functions directly Change-Id: Ia80a5c0438ed28ab3f9bd91b19494a19875bcab3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106858 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-11-30split CopyBits into two functionsCaolán McNamara
to capture that if pSrcGraphics is non-null then pSrcOutDev is always non-null and that if pSrcGraphics is null then pSrcOutDev is unused Change-Id: I7b1ecb35724ef9a7afb4ab4021b33e9f00a9ea3a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106808 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-11-28drawOutDevDirect always passed a non-null OutputDevice*Caolán McNamara
likewise: DrawOutDevDirectProcess ImplDrawWavePixel DrawOutDevDirectCheck and various members of SalGraphics dropping redundant nullptr checks Change-Id: Iaa1ab7c8a605361a7c9cce0aeee974eec9ff246e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106788 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-11-27with RTL UI the LTR scrollbar in 'gen' calc is rendered incorrectlyCaolán McNamara
this is noticable since... commit 4deadc3c78949c18bb886eb1f66caa8f3cd7a2df Date: Fri Sep 25 13:30:11 2020 +0200 disentangle AA and B2D use in VCL drawing but is probably a problem since around... commit b5f081e1ac14f60497f62a27be86b07b0baa42f7 Date: Thu Aug 30 23:41:36 2018 +0200 Support RTL layout in VCL using Matrices Change-Id: I6bcad30982ee1eaee96bc6721d73e1e545f0d86a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106761 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-11-14remove SalPointNoel Grandin
<caolan> that "SalPoint" doesn't really seem to to have a purpose except to highlight that "Point" is assumed to use LONG under windows and can be passed unchanged to those windows drawing apis <caolan> so I guess remove SalPoint entirely, use Point instead, and convert to "POINT" under windows ? Change-Id: Ic15a7f4516e2075a228fa65cac4e8494d5b3abaa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105634 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-19use tools::Long in vclNoel
Change-Id: Ice1055021e8568634e9a66ba89d3bb4ef4e731df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104522 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-28rename for disentangling AA and B2D use in VCL drawingLuboš Luňák
This renames AntialiasingFlags::EnableB2dDraw to just Enable, and the AntiAliasB2DDraw names to just AntiAlias. This is in preparation for a second commit that will actually separate the AA and B2D functionality of these flags. Change-Id: I9cc215c5752dfabce41e00e19d9074fc8dc3d4de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103416 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-09-15WIN OSX Qt5 unify CreateFontSubset codeJan-Marek Glogowski
This is basically just some refactoring. Most interestingly the MacOS used to work with 257 glyphs. I couldn't find any explaination for the 256 glyph limit. Sadly the PrintFontManager is out of scope. That needs more inspection. Change-Id: Ibfa0e905f5efeb7d4a609884d64b4ed2615a9d3d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102688 Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> Tested-by: Jenkins
2020-09-15Replace FindCmap with ParseCMAPJan-Marek Glogowski
This introduces a potential performance regression, because FindCmap works on the existing font tables and just sets up a lookup function, while ParseCMAP creates some optimized, in-memory lookup table, which needs a bit more work, but is faster in its usage, I think. At least the initial usage is faster the old way, as the CMAPs aren't decoded at all. As you can see, the old code is just used on Windows and MacOS / iOS. Deep in the bowels of the PrintFontManager, the CMAP is also decoded using ParseCMAP... So I'm not sure this potential regression really exists. Most fonts will already have a decoded CMAP, so my guess is this is actually faster in the end. No idea, how to measure. Change-Id: I52caac1264cd3ff11a2a3fa6e9c800f67f146a79 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102685 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-15WIN OSX unify GetGlyphWidths codeJan-Marek Glogowski
Now that GetFontChatMap is a member of PhysicalFontFace, we can copy the common part of both architectures into a SalGraphics helper function. Change-Id: Iad379ea690a1c5346b69b5042188506ccf575cc2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102684 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-08-25tdf#136094 Handle background color in drawNativeControlMichael Weghorn
Make gtk3's 'GtkSalGraphics::drawNativeControl' take into account a control's background color, if any is explicitly set: Set background/fill color (in 'Edit::ApplySettings') also for the case where the control is drawn "natively", but don't draw the background in the generic 'Window::Erase' method for the case of native drawing; instead handle it when drawing the control itself. This adds an additional parameter to pass the background color to the relevant '{d,D}rawNativeControl' methods (defaulting to 'COL_AUTO') and implements the required handling to apply the background color for the gtk3 case. qt5/kf5 will probably be handled in an upcoming commit as well. Windows as well as the "gen" VCL plugin were not affected by the issue, so remain unchanged and just ignore the new parameter. In a quick test on on macOS, the rendering of the controls in the sample doc was broken beyond just the missing background colors (s. screenshot attached to tdf#136094); the behavior there also remains unchanged by this patch, the new parameter is ignored for now. Change-Id: I01923a504fea2367ae96032104f09099e35f410e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101284 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Michael Weghorn <m.weghorn@posteo.de>
2020-07-20tdf#134085 DrawTransformedBitmap in wrong place for RTLCaolán McNamara
The return of mirror wasn't used, so no effort at a rtl mirror was made anyway. Looking at the similar case of polygons, the highlight polygons in the recently used view are also missing, they have also been misplaced we don't want to mirror polygons, we want to translate them to appear at their mirrored bounding box. Change-Id: Iefd853883bb6b99a352ce6969ceef7bd57046bc2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98982 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-05-24GetSysFontData is newly unusedCaolán McNamara
and thus SystemFontData Change-Id: I563a6b7c251194cd73c6b0026d4ae8485a057b28 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94740 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
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-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-27Add getting of render backend name + impl. for skiaTomaž Vajngerl
Change-Id: Id4e32425579c2a3ebdc33e234f55a7324dbb39d4
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-10-18cid#1454633 silence Uncaught exceptionCaolán McNamara
Change-Id: Id75da775ce247c06541d9f4e7d12b4928336cbd4 Reviewed-on: https://gerrit.libreoffice.org/81019 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
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-08-12Fix typosAndrea Gelmini
Change-Id: I151508c5d0b5d010f55d2324d36659ab5715a70c Reviewed-on: https://gerrit.libreoffice.org/77274 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
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-03-08make it possible to use FileDefinitionWidgetDraw in more backendsTomaž Vajngerl
Change-Id: I8871eb49e11d8c72c469230967c3c979091a0f9b Reviewed-on: https://gerrit.libreoffice.org/68898 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
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>
2018-12-08Clean up LIBO_INTERNAL_ONLY uses of SAL_WARN_UNUSED_RESULTStephan Bergmann
Change-Id: I98b2d90c8345f07010f6defd82557188d5cd35c7 Reviewed-on: https://gerrit.libreoffice.org/64808 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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-29tdf#42949 Fix IWYU warnings in include/vcl/[i-m]*Gabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: If1b2e04872eb0dd6725802c1709a9085f4cd8c91 Reviewed-on: https://gerrit.libreoffice.org/64141 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2018-11-09custom widgets: Fix various warnings.Jan Holesovsky
Change-Id: I5d657fa4d6f63b93ad3775a5641d08c6e0f3a615
2018-11-09custom widgets: Custom Widget ThemesTomaž Vajngerl
Change-Id: I7ec57d18fe99f906aeb6dbb40d0d30c2ac8b51c4
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>
generated by cgit (git 2.34.1) at 2025-04-28 03:22:23 +0000