summaryrefslogtreecommitdiff
path: root/vcl/inc/salgdi.hxx
AgeCommit message (Collapse)Author
2024-11-21use default implementation for drawEPSNoel Grandin
so only the one that implements it needs to override it Change-Id: I19e79c5746dbbebbf5914922587016fd03a902d4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176848 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-11-20use default implementation for hasFastDrawTransformedBitmapNoel Grandin
so only the one that implements it needs to override it Change-Id: I1acffb4796d95d75edc4507f533d9b1f8987972b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176790 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-10-31tdf#163457 CairoSDPR: Need to apply 'damage' to gtkArmin Le Grand (allotropia)
If a CairoSDPR does directly render to a Window the changes do not get reliably visualized due to the Cairo backend and gtk/QT usage being dependent of being told what 'damage' is done to refresh the window accordingly. The VCLCairoBackend is doing that, but without reach from the outside. Note that this is a rare case, in fact the 1st one discovered where a CairoSDPR is painting to a Window directly, see comments in the task. Even this occasion should not do that - showing the Comments in Calc on the Overlay would be major to just painting to the Window roughly. There are other possible workarounds (also see comments in the task), but just adding to be able to set the needed 'damage' in case target is a Window is simplest and potentially the fastest way to do this. Since usage of CairoSDPR is bound to use GetSystemGfxData anyways it is okay to react there and call a method ApplyFullDamage that exists on Graphics when the flag USE_HEADLESS_CODE is active. That forwards to the CairoCommon being responsible for that Window and does the minimal necessary to apply 'damage' to the full Window. This is done when constructing the CairoSDPR, thus from the timing that incarnation can then paint anything and it seems that at the next occasion something can handle the callback from gtk all is painted. If that should change it may get necessary to separate the usage of ApplyFullDamage from GetSystemGfxData, but works as intended for now. Change-Id: I5442f3413e43418954da29a18d66dea27e25e655 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175794 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2024-10-22pass by reference for ShouldDownscaleIconsAtSurfaceNoel Grandin
because the param is never null Change-Id: I58660a9e4e6c25def2a70099bffce322b477b702 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175415 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-10-16loplugin:unusedmethodsNoel Grandin
Change-Id: I6ba4b4046190b701d4a15c6fa90b6009ecf4ab1c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175014 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-08-05CairoSDPR: direct text rendering using CairoArmin Le Grand (Collabora)
I have added basic support for the text primitives (TextSimplePortionPrimitive2D) to the SDPR Cairo renderer. It can now basically render Text using a fallback to the already existing CairoTextRender. NOTE: This is not yet complete, but for discussion. Change-Id: I9b0c7b6bb4892905576593ef4e2b4071c7663c63 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171429 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2024-03-16reduce symbol visibility in vclNoel Grandin
Change-Id: Ia56bb092a4634e301ff8922ae63e6f7ede874d80 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164865 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-08-23tdf#146619 Remove unused includes from vcl/incGabor Kelemen
Change-Id: I8fbe02547d5045cfdb5021720b10ddd10106209a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155750 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-07-31all drawPolyPolygon variants return true nowCaolán McNamara
since: commit 4998de76ed1da4039e30718941d50d6f1dfe4f82 Date: Sun Jul 30 07:40:48 2023 +0000 tdf#156230: Drop freshly unused GenPspGfxBackend Change-Id: I7fc2a068f807777ed392c5d58772d130bf7f51c8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155076 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-07-03Rename and move header next to other font headersKhaled Hosny
Change-Id: I5485817b5a6c2e9538ed6fb00893663d09e7fa26 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153869 Tested-by: Jenkins Reviewed-by: خالد حسني <khaled@libreoffice.org>
2023-07-03Rename ImplFontMetricData -> FontMetricDataKhaled Hosny
Change-Id: I0f8753a5ef1865f4ea0431125e74d0f52aa1c396 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153868 Tested-by: Jenkins Reviewed-by: خالد حسني <khaled@libreoffice.org>
2022-12-21No need for bool return value hereNoel Grandin
all of the implementations of this method return true. Change-Id: I6dc02499af1809110edd482a48d9f6d5d42ead19 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144620 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-10-01vcl: Use PhysicalFontFace::GetRawFontData() for font embeddingKhaled Hosny
Change-Id: I6f7c4508f7cef022eaf65a998cb242078d3771c6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140826 Tested-by: Jenkins Reviewed-by: خالد حسني <khaled@aliftype.com>
2022-09-14Related: tdf#144583 move current lok hidpi icon thing into SalGraphicsCaolán McNamara
Change-Id: If34a2b15aebc5316783d72564ede23e02db04302 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139944 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-09-13vcl: Move subsetting helper functions to sft.cxxKhaled Hosny
No functional change. Change-Id: I8de9117c1b1b1fef251e2711287dbdadaccc4d74 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139799 Tested-by: Jenkins Reviewed-by: خالد حسني <khaled@aliftype.com>
2022-09-11vcl: Move CreateFontSubset() to PhysicalFontFaceKhaled Hosny
Having it in SalGraphics is not necessary as the code now depends on PhysicalFontFace for accessing raw font data, and this consolidates all the near identical copies of this code into one. Change-Id: I8a411f102fd2188a456bdeb8a0d794078d74e47b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139762 Tested-by: Jenkins Reviewed-by: خالد حسني <khaled@aliftype.com>
2022-09-06vcl: Drop unused SalGraphics::CreateFontSubset() argumentKhaled Hosny
pWidths is always nullptr. Change-Id: I1c666f146865786269e9513cbb6c8ffdc7df96e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139461 Tested-by: Jenkins Reviewed-by: خالد حسني <khaled@aliftype.com>
2022-09-06vcl: Drop now unused SalGraphics::GetGlyphWidths()Khaled Hosny
Change-Id: Iec8974d6fc67d9d599c5e92aa325225963da0021 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139459 Tested-by: Jenkins Reviewed-by: خالد حسني <khaled@aliftype.com>
2022-08-26automatically set TextRenderModeForResolutionIndependentLayout if we scaleCaolán McNamara
Always render glyphs with a mode suitable for rendering of resolution-independent layout positions if we scale the text positions. The idea being to typically continue to use the system defaults for font settings for UI elements, but where we are rendering into application canvases where there's a mapmode set then automatically use a good mode to render that. Change-Id: I0e5857e377da72ae1a2ede1d88d6408819fc9200 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138324 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-05-04Related: tdf#131725 match the basegfx translation to the mirror logicCaolán McNamara
that is used in the traditional code path, this will fix vcl RTL scrollbars in otherwise LTR UI Change-Id: I1451f7e17b93b0339ded6d33147df6415274ebfc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133780 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-01-13allow selecting text rendering mode suitable for natural glyph positionsCaolán McNamara
Change-Id: I6b8c815fda3a48917467719432071c0716e3e9ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127338 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
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>
generated by cgit (git 2.34.1) at 2025-01-05 09:37:23 +0000