summaryrefslogtreecommitdiff
path: root/vcl/inc/headless
AgeCommit message (Collapse)Author
2022-05-08ofz#46607 Integer-overflowCaolán McNamara
Change-Id: Id759423176b2e47fc00b8e7babd936b480956617 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134025 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-03-24loplugin:constantparamNoel Grandin
Change-Id: I6bfbd0cb5c2eac60bdac69fd862154fb2f537a89 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132030 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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 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-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-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-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-10Revert "Re-Enable DrawTransformBitmapExDirect for render backends"Armin Le Grand
This reverts commit 7e5af164b7d293dd410710bed411e1ca64bbecf7. Reason for revert: Not the best/effective way to clear out the stuff remaining to be done, would need additional stuff Change-Id: Ia6ab90384da29a5e34eff0ab8881bad2ab49c58c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126601 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2021-12-07Re-Enable DrawTransformBitmapExDirect for render backendsArmin Le Grand (Allotropia)
Unfortunately the add/usage of HasFastDrawTransformedBitmap did disable the system-dependent implementations/fast-path for DrawTransformBitmapExDirect and it's implemenations, except for Skia. This means that the current backends for Windows/Mac/Cairo/headless/Qt5 have to do expensive pixel operations when a Bitmap is 'really' transformed (rotate/shear) since some time. The nine implementations using ::hasFastDrawTransformedBitmap (grep for it) all return false, except the Skia one. Since HasFastDrawTransformedBitmap() uses that and itself is used in the very central mehod OutputDevice::DrawTransformedBitmapEx(...) to decide if that fast-path shall/can be used at all, it was *no longer used* - except for Skia - what makes Skia definitely performing better with transformed Bitmaps, or the other way around - the others worse. HasFastDrawTransformedBitmap() is used in only two places, the second is in the canvas helper to decide if to try to use that fast-path for presentation rendering. A method at OutputDevice to see if that fast-path is implemented is therefore currently needed, but for the canvas helper only. Since this will/should be converted to primitive usage (hopefully) anyways, nine impementations calling these virtual functions often and the danger to produce a mismatch/ error beween implementations of hasFastDrawTransformedBitmap and drawTransformedBitmap (as happened here, but can also happen when someone adds or removes an implementation) I looked for a way to solve that differenly and more safe. Since SalGraphics::DrawTransformedBitmap anyways returns a bool to signal it's success I take this as base to implement a buffered test directly at SalGraphics, also directly set a local flag to detect that functionality if DrawTransformedBitmap is used anyways before the test is/would be needed. Combined wih that small test to check only if this was not yet used and thus tested by DrawTransformedBitmap anyways I can offer a reliable non-virtual method at OutputDevice called ImplementsFastDrawTransformedBitmap() that will be used at the single necessary location - in the canvas helper. Since that small test direcly uses one of the nine implementations of hasFastDrawTransformedBitmap it is fundamenally more reliable and probably the copy bitmap/writeBack never really used (I tested that it works) due to an earlier use of DrawTransformedBitmap did the check potentially already. I also took a look at the cairo version (since I had this one running here) and ensured that the buffering of the system-dependent form of the Bitmap as cairo surface still works. Regarding the newly introduced fAlpha parameter I want to add some remarks: - It should be called fOpacity to make clear that it describes opacity, defining that if 1.0 == fAlpha means *no* transparency. That word is used in other graphic systems and makes more clear what function it has. It is the opposite of transparency, but works the same. - Currently all implementations of ::drawTransformedBitmap - except Skia where it was implemented - do not use it, but return false. It will in most cases not be too complicated to add/implement it, e.g. for cairo anyways a transparency surface will/is created, fAlpha can just be merged in, and the criteria for buffering that may be extended to remember for which value (if at all) of fAlpha that was prepared. I strongly recommend implementing these for our main graphic backends. - The primitive renderer uses another more general way to add an extra alpha channel to paint when needed - it draws the content (any content) that needs to be transparent to a buffer and then that buffer using the intended transparency. This is discussable since may be more expensive, but more general and keeps the interface less complex. We can see here that adding that complexity to the existing interface at OutputDevice makes the implementations more complex what might be the reason his was only implemented for one of nine backends. When adding something like this and extending the complexity I would prefer that at the same time it gets also *implemented* in all or most or at least most used cases. I want to make clear that from my POV in those cases choosing possible runtime speed over complexity is not always preferable. Change-Id: I5bab59f59fca878a7b11a20094e49e8b50196063 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126480 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2021-11-30svp: normalize DoYieldJan-Marek Glogowski
I somehow missed / forgot, that SvpInstance::DoYield was now also yielding on the main thread and doesn't try to do "funky" multi- threaded event processing anymore (because it's no GUI), since commit 0efd06de8fca4036c4132b2745a11273b1755df2 ("vcl: fix hangs in SvpSalInstance"), So this just moves the main thread part into ImplYield and implements DoYield like on all other architectures, as described in README.scheduler. I've tried to fix the LOK poll to be more sensible. Change-Id: I4323685aa250e9d62a2f448cef358a7aa8ae862c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117899 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
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-05tdf#143148 - Use pragma once instead of include guardsChris Sherlock
Done in preparation for movement of PhysicalFontCollection to vcl::font namespace. Change-Id: I17f27afd3ff0763866f3b2c169f7ee100d7f26d4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122406 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-10-04Add sal/config.h in preparation for patchChris Sherlock
The convention is that we need to add sal/config.h to the start of files. Made in preparation of movement of PhysicalFontCollection to vcl::font namespace and test class. Change-Id: I7768d9b4c7335f0d9feeba96f0dc67aaaaf8441e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122259 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-09-08vcl: remove CustomWidgetDraw as it is not needed anymoreTomaž Vajngerl
CustomWidgetDraw was the first implemetation for custom drawing of widgets, which was now replaced by FileDefinitionsWidgetDraw so CustomWidgetDraw is not needed anymore. Change-Id: I1c7a9fcf720bbfd91d9c44ad4b15a7281a0d0e14 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121740 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-08-20VCL allow plugins to declare OpenGL supportJan-Marek Glogowski
... and get rid of the whole GetBackendCapabilities, which was just overkill. Maybe this should even be some bitmap + enum + set/get function, but I'm too lazy... In the end add a bool for the OpenGL support of the VCL plugin (or maybe sticking it into ImplSVData, which is already some catchall for common VCL data). Change-Id: I9f0ececac482d8e2a94ef6024628e9631b49e773 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120760 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-08-18loplugin:passstuffbyrefNoel Grandin
Change-Id: I4f01eb3842ef198f02af274f54afb2760c820a4b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120655 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-30svp: add ostream<< for SvpSalFrameJan-Marek Glogowski
... and also store the window title. Change-Id: I20d8b30f6e8e5c48740fe569d9689a117db11e6d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118129 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-06-10loplugin:unnecessaryreturn SalFrame::SetPluginParentNoel Grandin
Change-Id: If927a834f5b5d722fc36cce40e161597af6234ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116972 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-10avoid possible repeated cairo surface creationLuboš Luňák
Doing the frame size adjustments only after the if condition meant that in headless mode the surface could be destroyed and created again for the same size. Also AcquireGraphics() passed different frame size to SetGraphics() than SetPosSize(). Change-Id: I9d6884a3917dfbd7b2cfe4fcd4e350c8bc9f4305 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116272 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
generated by cgit (git 2.34.1) at 2025-01-25 22:09:09 +0000