summaryrefslogtreecommitdiff
path: root/vcl/headless
AgeCommit message (Collapse)Author
2022-02-02fix std::min() used instead of std::max()Luboš Luňák
In 534fc16a9f8cd01bb88485e2cf6b9cd33aed3745 I got this backwards, if the value is not supposed to be 0, then it should be at least the small value, not at most. Change-Id: Ic55d2b2402985d26e77be0d1605b9ba5985b5ac7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129277 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-01-26make sure to not divide by zero when computing miter limitLuboš Luňák
The minimal angle is valid only if the line join style is miter, and e.g. FileDefinitionWidgetDraw can call these with round join style and 0 angle, which would divide by 0. So either clamp the value or compute it only when needed. Change-Id: I2a2c71481490c03ec6d01b8e33cab991400adb35 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129006 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-01-25don't use oversized surfacesCaolán McNamara
which leads to warnings of "rendering text failed with stretch ratio of: 10, invalid value (typically too big) for the size of the input (surface, pattern, etc.)" on my 200% scaled hidpi a problem since: commit cf9be3417bc2be5f772c03180b7cbd248b82cad5 Date: Tue Jan 11 19:08:50 2022 +0100 avoid Xlib cairo surfaces for small virtual devices (bsc#1183308) where the nNewDX/nNewDY passed to the cairo_surface_create_similar branch should remain as the unscaled sizes. This does change the meaning of (nNewDX <= 32 && nNewDY <= 32) for the hidpi case, but presumably that's ok Change-Id: I663a399c0e9c8480437a5663329cf753d69eb155 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128938 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-01-25log where cairo surface error really startedCaolán McNamara
otherwise later seen at: vcl/unx/generic/gdi/cairotextrender.cxx:283: rendering text failed with stretch ratio of: 10, invalid value (typically too big) for the size of the input (surface, pattern, etc.) Change-Id: Iaf65213bbfcf64f09bae8c83efea75e70b8a9c4d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128937 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-01-24avoid Xlib cairo surfaces for small virtual devices (bsc#1183308)Luboš Luňák
The (private :( ) document contains a large number of small shapes for which VclProcessor2D::RenderTransparencePrimitive2D() gets called, which results in GetBitmapEx() on the VirtualDevice. And Cairo normally needs to do a roundtrip to the XServer to fetch the content, which makes the rendering pretty slow. Forcing image-based surface for small sizes of VirtualDevice actually has better performance for the document, and the lack of possible HW acceleration generally shouldn't matter for a surface this small. Additionally drawinglayer's VirtualDevice reusing tries to reuse even a large one when a small one is needed, so a hack is needed to avoid that in this case, I couldn't find a better way. Change-Id: I0f58659ab88165a6bd915f100fc3b1d4802a0fa9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128309 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-01-20WASM --enable-wasm-strip now skips lots of LO codeArmin Le Grand (Allotropia)
... resulting in a stripped-down, Writer-only build to decrease the resulting WASM bytecode size. It removes the following code from the build: * All other major modules: Base, Calc, Chart, Draw, Impress and Math and related writerperfect filters * The premultiply tables * The (auto-)recovery functionality * All accessibility (but not the accessibility document checker) * The LanguageGuess component * EPUB support * The start center / BackingWindow * The TipOfTheDay functionality * The splash screen communication Currently crashs with anything different then soffice --writer. Closing the document also still crashes. FYI: many of these features are now behind ENABLE_WASM_STRIP_* defines, but they normally don't work on their own, globally! That's because we started with stripping the main components. Change-Id: Ib9c0f9452815910c0a2aceaf142ba1ad4a9cb0d7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126182 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-01-18Add HAVE_(UNIX_)DLAPI config header defineJan-Marek Glogowski
..., add the configure test flags and rename DLOPEN_LIBS to UNIX_DLAPI_LIBS. Initinally convert two dlsym callers to use HAVE_DLAPI and osl_getAsciiFunctionSymbol. There are a lot of places, which still use -ldl and even more direct dlsym calls; good opportunity for many simple EasyHacks. Change-Id: I4f2d2f7cb079a075af8f9d01eb5ee45de40c7f03 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128523 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-01-17iOS+SVP convert remaining VCL plugins to salplugJan-Marek Glogowski
While this makes the preprocessor usage even larger, the code in salplug.cxx is now hopefully easier to follow. I added a comment about the main code structure at the beginning. It also includes changes to the generic plugin list to include gtk3_kde5 before gen, qt5 and qt6 after gen, but still skips the headless / svp plugin. And I explicitly excluded salplug.cxx from the externandnotdefined compiler plugin. I could have added a dummy, but that seemed not worth the effort. My try on a non-dummy with correct includes and defines made the code in salplug.cxx much harder to follow. FWIW, the iOS VCL plugin actually seems to use the osx SalData, so I think these changes to iosinst.cxx are more correct then commit 7d990aafdc363b2a12b5db78637d7f3bef7780bd ("VCL drop m_pInstance from *nix SalData"). But hard to tell without a compiler. Change-Id: I0e2944d4221ca5910fb2120cc8b24def5c5b3f33 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128477 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-01-14VCL move SolarMutex (un)locking into (De)InitVCLJan-Marek Glogowski
Fixes all the backends, where SolarMutex access needs SalInstance. The ImplSVData::SalInstance is just set fron the return value of CreateSalInstance, so it can't be accessed earlier, globally. Regression from commit ad94bb5d23d9c4ecbb2ca84807f01623862de43e ("VCL drop m_pInstance from *nix SalData). Change-Id: I13259009571a9973ea7e3ded20c0ea4c660ee214 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128420 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-01-14VCL drop m_pInstance from *nix SalDataJan-Marek Glogowski
AKA the "*nix SalData untangling" commit. The original plan was to get rid of vcl/inc/saldatabasic.hxx and even SalData for all the *nix backends. But after many backs and forths, reinspecting the code and imagining the resulting code, I decided against that plan. All these variants would have resulted in reinterpret_cast calls, I wanted to prevent. And they would have required larger renames for no benefit. An other, related idea was to include all SalData implementations in the vcl/inc/svdata.hxx header, but that seemed like an include explosion, so was also dropped. I tried to untangling iOS from using GenericUnixSalData, as it doesn't use any of it's features. The new, minimal SalData should be sufficient. I'm leaving the easier drop of mpInstance from the Windows and MacOSX backend as a minimal interesting EasyHack. Change-Id: I5be01c1f42131a7e31cb30899392308e1e2de53b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128402 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-01-14ofz: fix build. error: missing member 'm_pPIManager'Caolán McNamara
probably since... commit bc3f70f220091f09ad02c148a6a49fdccb7b85c5 Date: Thu Jan 13 20:15:39 2022 +0100 VCL move PrinterInfoManager into GenericUnixSalData ... and use a std::unique_ptr. Change-Id: I07ffed4f722e30269ddf4828ffba3ac34952adb2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128417 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-01-14iOS+Android+SVP "merge" all SalData instancesJan-Marek Glogowski
It's always the same code. Change-Id: I2385d0bda24939b964306e27a3df99ea44356eac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128401 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-01-12don't bother trying to draw stuff which is effectively invisibleNoel Grandin
speeds up rendering of complex drawings with fine lines Change-Id: I62924c5ddb6293f993eef9ca200a43cba753d53e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128312 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-01-05vcl: cleanup SvpSalGraphics includesTomaž Vajngerl
Change-Id: I16619e55acfff7510803aff7ebf27c8d892a0d75 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127983 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-01-05vcl: move getBitmap to SvpGraphicsBackendTomaž Vajngerl
Change-Id: Ic72e1fdd3994a5bffef40bb70b713f10c1112903 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127982 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-01-05vcl: move drawAlphaBitmap to SvpGraphicsBackendTomaž Vajngerl
Change-Id: I182d775318a9b43a5955a5868e78a4b09c4a74c6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127981 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-01-05vcl: move drawBitmap, drawMask functions to SvpGraphicsBackendTomaž Vajngerl
Also fix the QTSvpGraphics that uses a special drawBitmap (renamed to drawBitmapBuffer) call and moved in also to SvpGraphicsBackend. Change-Id: Ic50630ba23e35a62ea3d5aaa0955a7666f2bca68 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127980 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-01-05vcl: move tryToUse{Source,Mask}Buffer to BitmapHelperTomaž Vajngerl
Change-Id: I9352aec388db56596fef3f5f323244b1df26cdcb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127979 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-01-05vcl: move SystemDependentData classes to BitmapHelperTomaž Vajngerl
SystemDependentData_BitmapHelper, SystemDependentData_MaskHelper to BitmapHelper.{hxx,cxx} files. Change-Id: I23f3b4badd8e262c442e5c6387876b078f22fd73 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127926 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-01-05vcl: move estimateUsageInBytesForSurfaceHelper to CairoCommonTomaž Vajngerl
Change-Id: I3c4140f99db4867109b04416317b96b268d9d8c5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127925 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-01-05vcl: move BitmapHelper and MaskHelper into own fileTomaž Vajngerl
Change-Id: If6f2a489be7cb51f62c55a2d4c804fcc741579bf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127924 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-01-04vcl: move SurfaceHelper class to CairoCommonTomaž Vajngerl
Intermediate step beore moving bitmap related members. Change-Id: Icf2d4cfb787dfb029f299cba4b4ffabae563bf6d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-01-04vcl: move Toggle1BitTransparency to CairoCommonTomaž Vajngerl
Intermediate step beore moving bitmap related members. Change-Id: Iaa30fd53d3b14c08fd502b33d370950569994139 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127922 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-01-04Drop all commented SAL_DEBUG callsJan-Marek Glogowski
Change-Id: I3be7153d27b83766303519e73d1a355ba327871a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127929 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-01-04vcl: move FastConvert24BitRgbTo32BitCairo to CairoCommonTomaž Vajngerl
Intermediate step beore moving bitmap related members. Change-Id: Ic0adff8ba8fadd0687ec903460e0caf7507e99b6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127846 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-01-04vcl: move createCairoSurface to CairoCommonTomaž Vajngerl
Intermediate step beore moving bitmap related members. Change-Id: Ia3321ddd1ca3adb11e2b4610c3fb6b0be5ee6515 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127845 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-01-04vcl: drawAlphaRect to SvpGraphicsBackendTomaž Vajngerl
Change-Id: I44f388b6578d4f9e7d0e5b75e17fab534574da1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127844 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-01-04vcl: move empty blendBitmap, hasFastDraw,.. to SvpGraphicsBackendTomaž Vajngerl
Moves blendBitmap, blendAlphaBitmap, hasFastDrawTransformedBitmap, supportsOperation to the SvpGraphicsBackend. Most these are empty stub implementations that aren't supported by the backend. The exception is supportsOperation, which already had been implemented but not removed from svpgdi.*xx files. Change-Id: I240a803d9a8614f1c4ed763a8fc34296202045fa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127843 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-01-04vcl: copyArea and copyBits to SvpGraphicsBackendTomaž Vajngerl
Also move the used (sub)functions to the CarioCommon: copyBitsCairo, copySource, copyWithOperator, renderSource and renderWithOperator. Also use these functions in some calls needed by drawBitmap & co. Change-Id: I51395953545827951b6f255a9833e828aec7ea60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127842 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-01-03vcl: (re)move drawEPS to SvpGraphicsBackendTomaž Vajngerl
Change-Id: Ic5936a0d5bfe566d75532ccff52f25bf502019ae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127827 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-01-03vcl: move invert to SvpGraphicsBackend and CairoCommonTomaž Vajngerl
Common invert to CairoCommon, 2 invert members on the interface to SvpGraphicsBackend calling the common invert call. Change-Id: I2fada75cc0d730f0708ae7ca934a51e1d17cef1c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127826 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-01-03vcl: move getPixel to SvpGraphicsBackendTomaž Vajngerl
Change-Id: I409581a2bdc9e18420bb159ce349fb5a5b86c463 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127825 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-01-01vcl: move drawGradient to SvpGraphicsBackendTomaž Vajngerl
Change-Id: Ifc3d0b0a693113b0cfbd763bf6ac0bd34eb6c872 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127824 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-01-01vcl: move (legacy) drawPolygon(.., Point*) to SvpGraphicsBackendTomaž Vajngerl
Change-Id: I5b3b915712921fbbdaa0b0d7ad9b9c39291e00f2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127823 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-01-01vcl: move drawPolyLine (+legacy) to SvpGraphicsBackendTomaž Vajngerl
Also moves drawPolyLine with cairo context param. to CairoCommon as it is also needed in X11SalGraphics::drawPolyLine. Change-Id: I49b24bc31ecf3f6ab3cebca4eaab351c91564db5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127740 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-01-01vcl: move the draw*Bezier methods to SvpGraphicsBackendTomaž Vajngerl
These methods only return false (for fallback implementation to kick-in). Change-Id: I167dda09d401e69ca4a2296e8024ab0f203b097a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127739 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-01-01vcl: move drawPolyPolygon(..., Point**) to SvpGraphicsBackendTomaž Vajngerl
This moves the legacy drawPolyPolygon, which takes a 2D array of points as the input. The implementation just converts it to a B2dPolyPolygon and calls the regular drawPolyPolygon. Change-Id: I5be8b818bcdf58a15e575b904ed20bb8f97bcffc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127738 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-01-01vcl: move drawRect and drawPolyPolygon to SvpGraphicsBackendTomaž Vajngerl
Also move add_polygon_path and SystemDependentData_CairoPath class to CairoCommon. SystemDependentData_CairoPath is temporary made public until other dependencies are moved too. Change-Id: I381407fc7c168c8982fcfd8c886cf622f95591fd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127711 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-12-30vcl: move drawLine to SvpGraphicsBackendTomaž Vajngerl
Also move getClippedStrokeDamage, AddPolygonToPath, impPixelSnap to CairoCommon, as it is needed by the move. Change-Id: I002f0094935e5f5d4836bb973f7cf7bea0218ff2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127710 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-12-30vcl: move drawPixel to SvpGraphicsBackendTomaž Vajngerl
Includes moving getClippedFillDamage and dependent functions to CairoCommon. Change-Id: Iea7c39377816c3639de1b97cea47efa71ca47315 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127709 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-12-30vcl: move applyColor and clipRegion to CairoCommonTomaž Vajngerl
Change-Id: I0a207b10017923c4336d49ebc8abd53c78d809ac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127708 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-12-30vcl: move getting and releasing cairo context to CairoCommonTomaž Vajngerl
The getting/creating and releasing of the cairo context is needed by the SvpGraphicBackend. Change-Id: I133b181b8a6b114e08c8acc4596ccefb88a3f514 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127707 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-12-30vcl: move lineColor, fillColor and paintMode to SvpGraphicBackendTomaž Vajngerl
The member variables are moved to CairoCommon. Change-Id: Ia03f613c7ad02ec2e7d70705c7666ec25d63f003 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127706 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-12-30vcl: move set and reset clip region tothe SvpGraphicBackendTomaž Vajngerl
The clip region variable now needs to be in CairoCommon and used in SvpSalGraphic and SvpGraphicBackend. Change-Id: I577ad2c3b6531a26089019ccbdc5e07398f70378 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127705 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-12-30vcl: pass CairoCommon to SvpGraphicBackend, move over some methodsTomaž Vajngerl
SvpGraphicBackend now accepts CairoCommon on construction, as we need it to move over methods. This moves over GetBitCount and GetGraphicsWidth, which also needs the frame size, that is added to CairoCommon. Change-Id: I362c9bed3ef0d85fc51f90a192cc20e06d7a45c0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127704 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-12-30vcl: Introduce CairoCommon to manage the cairo functionsTomaž Vajngerl
CairoCommon is needed so that SvpSalGraphics and SvpGraphicBackend can both access the same cairo constructs. Currently the common one is the cairo surface. Change-Id: Ia23c30489c9df889a348da5720ee84c82c792374 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127703 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-12-30vcl: Introduce SvpGraphicsBackendTomaž Vajngerl
SvpGraphicsBackend contains the implementation of the graphic drawing backend, which uses cairo for drawing. Currently the cairo based graphic drawing implementation is on SvpSalGraphics, but will be steb-by-step moved into SvpGraphicsBackend, just like with other vcl plugins. Change-Id: I70c94f08c5bd1d705f2faeacb66373ddf12f494a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127702 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-12-29Always use <poll.h>, no modern system needs <sys/poll.h>Ismael Luceno
This was standardized in IEEE 1003.1-2001, so more than 20 years old. Verified following systems using online resources: - FreeBSD 3.0 (1998) - NetBSD 1.3 (1998) - OpenBSD 2.0 (1996) - CentOS 5.0 (2007) - Debian 4.0 (2007) - IRIX 6.5.30 (2006) - SunOS 4.1.3 (1992) - SUSE 10.2 (2008) - Red Hat 5.0 (1998) So the check used for BSDs on vcl/unx/generic/dtrans/X11_selection.cxx was never correct. On GNU/Linux specifically, <poll.h> is provided since glibc 2.0 (1997). musl libc produces the following warning if the non-standard header is included: /usr/include/sys/poll.h:1:2: warning: #warning redirecting incorrect #include <sys/poll.h> to <poll.h> [-Wcpp] Change-Id: Ia8f4b9e1ee069f86abe03140c18a77d17336d09c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127666 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-12-10Revert "Re-Enable DrawTransformBitmapExDirect for render backends"Armin Le Grand
This reverts commit 7e5af164b7d293dd410710bed411e1ca64bbecf7. Reason for revert: Not the best/effective way to clear out the stuff remaining to be done, would need additional stuff Change-Id: Ia6ab90384da29a5e34eff0ab8881bad2ab49c58c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126601 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2021-12-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>
generated by cgit (git 2.34.1) at 2025-01-15 07:48:38 +0000