summaryrefslogtreecommitdiff
path: root/external/skia
AgeCommit message (Collapse)AuthorFilesLines
2021-04-14Revert "update Skia to chrome/m91" (tdf#141680)Luboš Luňák7-58/+139
The m91 snapshot seems to cause a number of Vulkan problems. My commit already worked around one, but there are apparently others, such as very slow startup, or a failed Skia assertion triggered by VCL Skia's copyArea(). This reverts commit 09d850e46903a528d4b08d3fdf03c3964d79fbc5. Change-Id: I4f1832ba76db15cab8eccbe115d21c989da3c841 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114089 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-04-12update Skia to chrome/m91Luboš Luňák7-139/+58
Change-Id: I82050e9695b9aa49c33ee16d345bb64595b00bbc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113978 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-03-29speed up SkiaHelper::dump() in Skia debug buildsLuboš Luňák1-1/+9
Change-Id: Ic5c4bb38e9b8c0c1bb0e3efc2c5ee7a3fa787d93 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113320 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-03-23Rename LO Windows arm64 ID to aarch64Jan-Marek Glogowski1-1/+1
The Windows platform is called Arm64. But now that the ID for Mac is also going to be renamed from arm64 to aarch64, this get's rid of the arm64 as the UNO identifier and user in gbuild, just like on all other Arm64 platforms. Change-Id: I60a7eafd04b426f17b6e41ad9a09e6405c0d4173 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112973 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-03-15less complicated Skia SSSE3 loopLuboš Luňák1-4/+2
I copy&pasted this from other code, but in this case it's simpler and less confusing to not overrun the output buffer. Change-Id: I782348d9870ac1e87c49e2267953c2f6299dbcd0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112537 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-03-03update Skia to chrome/m90Luboš Luňák8-151/+154
Including chrome/m89, which wasn't included before because of tdf#140023. Change-Id: I64f1de8e10eab2d92a9383ce8104be5afca40101 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111792 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-02-08Revert "update Skia to chrome/m89" (tdf#140023)Luboš Luňák7-116/+61
That update started using SkSamplingOptions to specify image scaling quality. Some places using SkImage::makeShader() should use the quality instead of default SkSamplingOptions ctor, but even with that fix the test document still uses the default nearest quality. Since chrome/m90 will introduce further changes related to this, I'll just revert to m88 and revisit this with m90. This reverts commit 2cf9b8e265e9694803f55e30f2f392abfa512a5a. Change-Id: Iea0e57b7e7b804675d393e4088532a6f617bfd43 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110541 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-01-20update Skia to chrome/m89Luboš Luňák7-61/+116
Change-Id: I82517728139a4b270d98e2694f2a21b248c80d4f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109568 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-01-11Fix -Werror,-Wundef in Skia (at least for Raspberry pi 4)Julien Nabet2-0/+16
Detected on Raspberry pi 4, for example: In file included from /home/pi/lo/libreoffice/vcl/skia/SkiaHelper.cxx:34: In file included from /home/pi/lo/libreoffice/vcl/inc/skia/utils.hxx:28: In file included from /home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkRegion.h:11: In file included from /home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkRect.h:11: In file included from /home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkPoint.h:11: In file included from /home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkMath.h:11: /home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkTypes.h:371:5: error: 'SK_CPU_SSE_LEVEL' is not defined, evaluates to 0 [-Werror,-Wundef] if SK_CPU_SSE_LEVEL >= SK_CPU_SSE_LEVEL_SSE1 ^ ... but there are others, see: http://document-foundation-mail-archive.969070.n3.nabble.com/Building-LO-on-Raspberry-pi-4b-error-unknown-attribute-externally-visible-on-jni-part-tt4293505.html Since it may happen on some other envs and it can't be bad to explicitely initialize this preproc var, it seems relevant to use this patch unconditionally. Change-Id: Icc5794fcd3139cbdbd8d57a6938d31aee51a3e2a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109047 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-01-07faster debug dumping for SkiaLuboš Luňák2-1/+17
Write out the png images as quickly as possible, with still at least minimal compression. Without compression the debug images are way too big, but otherwise it's preferred that this is fast (especially when possibly dumping thousands of images). Skia's PNG code ignores the quality and hardcodes the libpng defaults, so patch Skia to explicitly handle the quality we want. It'd be also possible to use SkPngEncoder directly, but SkImage makes it non-trivial to get at the pixel data if it's on the GPU, and the internal getROPixels() invoked by encodeToData() also caches the content, so be lazy and patch Skia. Change-Id: I09cc61115246de4fc9d076953eb7fec8140c32cb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108668 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-12-09better name for a helper Skia functionLuboš Luňák4-11/+11
What it really does is converting RGBA to R, so name it after what it does. That the result happens to be kind-of-grey of the RGBA is just a result of VCL providing the data that way. Change-Id: Ic017e34d91879679e0a7dad4d6ab35650fc3a89b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107408 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-11-18external/skia: UBSan needs GrContext_Base RTTI nowStephan Bergmann2-1/+34
...in vcl: > [GAL] sounds > instdir/program/gengal.bin: symbol lookup error: instdir/program/libvcllo.so: undefined symbol: _ZTI14GrContext_Base > make[1]: *** [solenv/gbuild/Gallery.mk:56: workdir/Gallery/sounds.done] Error 1 (I didn't check what source exactly causes UBSan to require it now.) Marking both the class and some of its members as SK_API would cause MSVC to fail with > error: attribute 'dllexport' cannot be applied to member of 'dllexport' class so remove it from the class members. Change-Id: I9f5ed397d32f1f445bfa1d70bcff494e78c16046 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106039 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-17update Skia to chrome/m88Luboš Luňák10-132/+153
Change-Id: I74c19597b07e9d07ee90e4191b75787241fdd845 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105829 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-10-16Rename CLANG_CC, CLANG_CXX configuration vars (avoid clash with scan-build)Stephan Bergmann1-7/+7
Clang's scan-build tool uses the CLANG_CXX environment variable (setting it up in the scan-build script to pass it to the ccc-analyzer script), but happens to erroneously set it to a non-existing path (see <https://reviews.llvm.org/D89481> "[scan-build] Fix clang++ pathname again"). So wrapping LO's autogen.sh and make in scan-build picked up that broken CLANG_CXX and caused build failures like > [CXX] external/skia/source/SkMemory_malloc.cxx > /bin/sh: ~/llvm/inst/bin/clang-12++: No such file or directory (see <https://lists.freedesktop.org/archives/libreoffice/2020-October/086113.html> "Re: llvm/clang static analyzer reports"). So rename CLANG_CXX, and for consistency also CLANG_CC and the various CLANG_CXXFLAGS_INTRINSICS_*, by prefixing each with LO_. Change-Id: Ib41cabe940f8bfb1997f74e865cca5725f859e07 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104383 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-08track dirty areas for Skia drawingLuboš Luňák2-0/+115
Updates to the screen in raster mode aren't _that_ slow, in fact it seems using SkRegion can make things slower because of manipulating the region, but with SkIRect this could sometimes help a bit. It also appears that StretchDIBits() that is used by the Windows raster code doesn't work correctly if only a subset of the y-axis range is specified, which reduces the usefulness. Change-Id: Ia93d2b60f2c62461e4c2c81210ab1d5d652a2cfb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104047 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-10-02skia: fix Windows Arm64 buildJan-Marek Glogowski1-0/+4
This uses MSVC instead of clang for this host. Change-Id: Idf96668e00563be12a7819a1658b657673733d21 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103780 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-30use -fpch-codegen rather than -fmodules-codegenLuboš Luňák1-1/+1
The -fmodules-codegen flag has been in Clang for quite a while, but it officially works with PCHs only with Clang11+, and even there's it's better to use the properly named -fpch-codegen. This also fixes a problem with Clang9 having only -fmodules-codegen but not the -fno-* variant, causing the build to break. Change-Id: I9a8c979426f95e8c1f77cbeab1df64390d7243b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103677 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-15disable Clang's -fmodules-codegen for Skia if optimizing itLuboš Luňák1-0/+1
Skia is explicitly made to build optimized even in debug builds, unless --enable-skia=debug is given, so $(PCH_MODULES_CODEGEN) gets set even for it by com_GCC_class.mk , although normally it's disabled for optimized builds as not worth it. Explicitly disable the flag for Skia. Change-Id: Icf030f0bdc99dbc476af585937c864f951d2b7ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102674 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-03fix offsets in our SSSE3 Skia functions (tdf#136326)Luboš Luňák1-2/+2
'src' is uint32_t, so that extra '*4' was wrong. Change-Id: Ie0628a72bd4f7eb3122e4b1d67b6bb759f74bc46 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102007 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-08-27remove some unused includes and update pchesCaolán McNamara1-4/+5
Change-Id: I786548bef39fa711aabcff32b592b3fdc4a6f9fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101486 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-27Fix `--disable-pch` buildMike Kaganski1-0/+14
... breaking after commit eaf4f6d3b1e64bc7b057e70cffe0bda0ed42c49f with this: In file included from C:/lo/src/build/workdir/UnpackedTarball/skia/tools/sk_app/win/VulkanWindowContext_win.cpp:13: In file included from C:/lo/src/build/workdir/UnpackedTarball/skia\tools/sk_app/VulkanWindowContext.h:17: In file included from C:/lo/src/build/workdir/UnpackedTarball/skia\include/gpu/vk/GrVkBackendContext.h:11: C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkRefCnt.h(141,12): error: member access into incomplete type 'GrDirectContext' obj->ref(); ^ C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkRefCnt.h(226,40): note: in instantiation of function template specialization 'SkSafeRef<GrDirectContext>' requested here sk_sp(const sk_sp<T>& that) : fPtr(SkSafeRef(that.get())) {} ^ C:/lo/src/build/workdir/UnpackedTarball/skia\tools/sk_app/WindowContext.h(24,1): note: in instantiation of member function 'sk_sp<GrDirectContext>::sk_sp' requested here WindowContext { ^ C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkImage.h(36,7): note: forward declaration of 'GrDirectContext' class GrDirectContext; ^ In file included from C:/lo/src/build/workdir/UnpackedTarball/skia/tools/sk_app/win/VulkanWindowContext_win.cpp:13: In file included from C:/lo/src/build/workdir/UnpackedTarball/skia\tools/sk_app/VulkanWindowContext.h:17: In file included from C:/lo/src/build/workdir/UnpackedTarball/skia\include/gpu/vk/GrVkBackendContext.h:11: C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkRefCnt.h(150,12): error: member access into incomplete type 'GrDirectContext' obj->unref(); ^ C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkRefCnt.h(251,9): note: in instantiation of function template specialization 'SkSafeUnref<GrDirectContext>' requested here SkSafeUnref(fPtr); ^ C:/lo/src/build/workdir/UnpackedTarball/skia\tools/sk_app/WindowContext.h(24,1): note: in instantiation of member function 'sk_sp<GrDirectContext>::~sk_sp' requested here WindowContext { ^ C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkImage.h(36,7): note: forward declaration of 'GrDirectContext' class GrDirectContext; ^ In file included from C:/lo/src/build/workdir/UnpackedTarball/skia/tools/sk_app/win/VulkanWindowContext_win.cpp:13: In file included from C:/lo/src/build/workdir/UnpackedTarball/skia\tools/sk_app/VulkanWindowContext.h:17: In file included from C:/lo/src/build/workdir/UnpackedTarball/skia\include/gpu/vk/GrVkBackendContext.h:11: C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkRefCnt.h(264,25): error: no matching function for call to 'SkSafeRef' this->reset(SkSafeRef(that.get())); ^~~~~~~~~ C:/lo/src/build/workdir/UnpackedTarball/skia\tools/sk_app/WindowContext.h(24,1): note: in instantiation of member function 'sk_sp<GrDirectContext>::operator=' requested here WindowContext { ^ C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkRefCnt.h(139,40): note: candidate template ignored: substitution failure [with T = GrDirectContext] template <typename T> static inline T* SkSafeRef(T* obj) { ^ C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkRefCnt.h(311,9): error: no matching function for call to 'SkSafeUnref' SkSafeUnref(oldPtr); ^~~~~~~~~~~ C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkRefCnt.h(264,19): note: in instantiation of member function 'sk_sp<GrDirectContext>::reset' requested here this->reset(SkSafeRef(that.get())); ^ C:/lo/src/build/workdir/UnpackedTarball/skia\tools/sk_app/WindowContext.h(24,1): note: in instantiation of member function 'sk_sp<GrDirectContext>::operator=' requested here WindowContext { ^ C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkRefCnt.h(148,42): note: candidate template ignored: substitution failure [with T = GrDirectContext] template <typename T> static inline void SkSafeUnref(T* obj) { ^ 4 errors generated. Change-Id: I159b9ef388834a454eff58c6c2eda2e13dddb67a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101439 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-08-26UBSan needs sk_app::WindowContext RTTI in Library_vclStephan Bergmann1-0/+15
...as seen during CppunitTest_basic_scanner: > DynamicLibraryManagerException: "Failed to load dynamic library: workdir/LinkTarget/CppunitTest/libtest_basic_scanner.so > instdir/program/libvcllo.so: undefined symbol: _ZTIN6sk_app13WindowContextE" Change-Id: I7c39d19fda3cdfe51b5ccf117ffe5c6c89863258 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101410 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-26update Skia to chrome/m86 snapshotLuboš Luňák12-197/+174
Change-Id: Id0c0679bc1ca546a75f71d4716ba151ae46569bd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101311 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-08-12SvTreeListBox can move into toolkit headers nowCaolán McNamara1-1/+2
Change-Id: I6b3b6ef1530a192f4b6bf87aa9688687063683ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100591 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-07Fix Skia build using VS 2019 v.16.7.0 with --disable-pchMike Kaganski2-0/+12
No idea if updated VS makes a difference, or some recent Skia update... In file included from C:/lo/src/build/workdir/UnpackedTarball/skia/src/core/SkBitmapDevice.cpp:11: In file included from C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkPath.h:13: C:/lo/src/build/workdir/UnpackedTarball/skia\include/private/SkPathRef.h(113,41): error: implicit instantiation of undefined template 'std::tuple<SkPoint *, float *>' std::tuple<SkPoint*, SkScalar*> growForVerbsInPath(const SkPathRef& path) { ^ C:/PROGRA~2/MICROS~1/2019/COMMUN~1/VC/Tools/MSVC/1427~1.291/Include\utility(126,7): note: template is declared here class tuple; ^ In file included from C:/lo/src/build/workdir/UnpackedTarball/skia/src/core/SkBitmapDevice.cpp:11: In file included from C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkPath.h:13: C:/lo/src/build/workdir/UnpackedTarball/skia\include/private/SkPathRef.h(114,30): error: implicit instantiation of undefined template 'std::tuple<SkPoint *, float *>' return fPathRef->growForVerbsInPath(path); ^ C:/PROGRA~2/MICROS~1/2019/COMMUN~1/VC/Tools/MSVC/1427~1.291/Include\utility(126,7): note: template is declared here class tuple; ^ In file included from C:/lo/src/build/workdir/UnpackedTarball/skia/src/core/SkBitmapDevice.cpp:11: C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkPath.h(1543,65): error: implicit instantiation of undefined template 'std::tuple<SkPathVerb, const SkPoint *, const float *>' std::tuple<SkPathVerb, const SkPoint*, const SkScalar*> operator*() const { ^ C:/PROGRA~2/MICROS~1/2019/COMMUN~1/VC/Tools/MSVC/1427~1.291/Include\utility(126,7): note: template is declared here class tuple; ^ In file included from C:/lo/src/build/workdir/UnpackedTarball/skia/src/core/SkBitmapDevice.cpp:11: C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkPath.h(1550,20): error: implicit instantiation of undefined template 'std::tuple<SkPathVerb, const SkPoint *, const float *>' return {verb, fPoints + backset, fWeights}; ^ C:/PROGRA~2/MICROS~1/2019/COMMUN~1/VC/Tools/MSVC/1427~1.291/Include\utility(126,7): note: template is declared here class tuple; ^ In file included from C:/lo/src/build/workdir/UnpackedTarball/skia/src/core/SkBitmapDevice.cpp:11: C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkPath.h(1625,68): error: implicit instantiation of undefined template 'std::tuple<SkPathVerb, const SkPoint *, const float *>' return (fIter != fEnd) ? static_cast<Verb>(std::get<0>(*fIter)) : kDone_Verb; ^ C:/PROGRA~2/MICROS~1/2019/COMMUN~1/VC/Tools/MSVC/1427~1.291/Include\utility(126,7): note: template is declared here class tuple; ^ 5 errors generated. make[1]: *** [C:/lo/src/core/solenv/gbuild/LinkTarget.mk:351: C:/lo/src/build/workdir/GenCxxObject/UnpackedTarball/skia/src/core/SkBitmapDevice.o] Error 1 Change-Id: Ica85829cf61d86e486cf4b2a730f50e06e3fb337 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100271 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-07-29optimize a bit more conversions to/from Skia bitmap formatsLuboš Luňák7-30/+208
It turns out this doesn't really matter in practice, since if converting between pixel formats is where time is spent, something higher must be already wrong. But since I've already written this... Change-Id: I25451664d529a9226d2d81b2c424a4f4e5422ad5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99577 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-07-21external/skia: Fix previous std::result_of_t -> std::invoke_result_t changeStephan Bergmann1-2/+2
...84c412cb8392d306ab87fc06855677612f9938a6 "external/skia: Deprecated std::result_of_t has been removed from C++20" Change-Id: I7d14306039dbcdbc9509471402299d8cbb9e48c8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99168 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-20external/skia: Deprecated std::result_of_t has been removed from C++20Stephan Bergmann2-0/+18
...and is no longer provided at least by VS 2019 16.6.4 when using --with-latest-c++ Change-Id: I4655e2a2b3c4c9411ee6f5b9b42137e1bd7ac3fb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99046 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-12update pchesCaolán McNamara1-4/+5
Change-Id: I75602277a5a26b012a12f2c4f4b7ff5bb663b0b9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98474 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-07-01update Skia to chrome/m85 snapshotLuboš Luňák9-68/+133
Change-Id: I3af3517c9c213e0db8365aecd0a008d817ca4dcf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97592 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-06-30direct 8bit gray -> RGBA conversion in SkiaSalBitmapLuboš Luňák1-4/+10
Change-Id: Ic77f9b8f9244e7fdaca78f91686645eee421d18f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97288 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-06-25log properly the compiler used to compile SkiaLuboš Luňák3-0/+35
Using #define's directly from VCL will report the compiler used to compile VCL, which may be different from the one used for Skia. Also truncate the log file on opening. Change-Id: Iddf613613df20505f1abe1dd5468dcc8c7041410 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97090 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-06-22add debugging hints to Skia READMELuboš Luňák1-2/+8
Change-Id: I32d9a8bf19cbff709c088c0e0a1d4830e877e88d
2020-05-20external/skia: Mark c++20.patch.0 as reported upstreamStephan Bergmann1-0/+2
Change-Id: Ia8434915829682880c0f2161f935d6608a18fd81 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94555 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-05-19external/skia: Adapt to C++20 rewritten equality comparisonsStephan Bergmann2-0/+11
...by avoiding the selection of rewritten ones that would use synthesized operator== with non-bool return type: > workdir/UnpackedTarball/skia/src/core/SkVM.cpp:1317:37: error: return type 'skvm::I32' of selected 'operator==' function for rewritten '==' comparison is not 'bool' > select(s == 0.0f , d * (1-src.a) > ~ ^ ~~~~ > workdir/UnpackedTarball/skia/src/core/SkVM.cpp:1217:17: note: in instantiation of function template specialization 'skvm::Builder::blend(SkBlendMode, skvm::Color, skvm::Color)::(anonymous class)::operator()<skvm::F32, skvm::F32>' requested here > fn(src.r, dst.r), > ^ > workdir/UnpackedTarball/skia/src/core/SkVM.cpp:1311:43: note: in instantiation of function template specialization 'skvm::Builder::blend(SkBlendMode, skvm::Color, skvm::Color)::(anonymous class)::operator()<(lambda at workdir/UnpackedTarball/skia/src/core/SkVM.cpp:1311:44)>' requested here > return apply_rgb_srcover_a([&](auto s, auto d) { > ^ > workdir/UnpackedTarball/skia/src/core/SkVM.h:912:23: note: declared here > static inline I32 operator==(float x, F32 y) { return y->eq(x,y); } > ^ (There are more such operators here that could cause similar issues, but I only adapted the one that caused the overall build of LibreOffice to fail.) Change-Id: Ib880191f8bfa44dacb65692e27f32d2e62a96371 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94473 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-05-18update to Skia chrome/m84 snapshotLuboš Luňák5-17/+60
Change-Id: I7c5ad1673776fd0991a61b4c9f9a947e42764f44 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94414 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-05-11avoid deep copies of pixels with Skia raster surfaces (tdf#132856)Luboš Luňák2-0/+40
SkCanvas::draw() leads to deep copies of the source bitmap, moreover RasterWindowContext_win allocates the pixels in a way that SkSurface_Raster has to do a deep copy because of not owning the pixels. Change-Id: I22f6a2c0f96faf99f94140eff26ec0c22fae96d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93958 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-05-11skia: add SkOpts_crc32Rene Engelhard1-0/+3
I get /usr/bin/ld: /home/rene/libreoffice-7.0.0~alpha1/workdir/GenCxxObject/UnpackedTarball/skia/src/core/SkOpts.o: in function `SkOpts::Init()': ././workdir/UnpackedTarball/skia/src/core/SkOpts.cpp:135: undefined reference to `SkOpts::Init_crc32()' collect2: error: ld returned 1 exit status make[2]: *** [/home/rene/libreoffice-7.0.0~alpha1/external/skia/Library_skia.mk:10: /home/rene/libreoffice-7.0.0~alpha1/instdir/program/libskialo.so] Error 1 on aarch64 otherwise Change-Id: I713df3438e48fb7cb08ecdb07a998d21068ab464 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93901 Tested-by: Rene Engelhard <rene@debian.org> Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-05-06always build Skia optimized, unless --enable-skia=debugLuboš Luňák1-0/+10
In raster mode the performance may make quite a difference, this is the drawing library (that's now the Windows default) and LO developers mostly do not need to debug Skia itself. Change-Id: I42f0407d37a2294b062a41d94566e8a4f5f4354b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93557 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-04-21better handling of SSEx,AVX intrinsics for ClangLuboš Luňák1-5/+6
Clang-cl interprets MSVC's -arch option a bit differently (for MSVC -arch:SSE2 seems to mean SSE2+, but SSE2-only for Clang). So use Clang's -mxxx options when using clang-cl as CC/CXX. Also check intrinsics once again if using CLANG_CC/CXX to compile Skia. Change-Id: I64cd368ef4e5f4fcf1dbe877a1129f418d273a47 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92618 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-04-20prefer building Skia with Clang if possible (tdf#131697)Luboš Luňák4-27/+26
I.e. try to find and use Clang even if the default compiler is something else. Skia is optimized to be built with Clang(-cl) and in CPU-based raster mode some operations are several times slower if built with something else (e.g. fmax/fmin do not get optimized to inline assembly). It is enough to select Clang to be installed in the MSVS installer. At this point it unclear how to handle release binaries, if it should work this way and enforced, or maybe Clang could be used for building everything, or maybe some other way. Change-Id: I6b95a0f2d5cbf176942d9e01136990b14be6dba8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92415 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-04-13skia: make gcc not crash again for x86 buildsThorsten Behrens1-18/+14
Papered over already with a bandaid in c13f75de521cfb67ca4db431708f8cd366b23587, happened again after skia upgrade; let's now fix th eICE on CentOS7 devtoolset-7's gcc proper. It appears that this error workdir/UnpackedTarball/skia/third_party/skcms/src/Transform_inl.h:696:13: note: The ABI for passing parameters with 16-byte alignment has changed in GCC 4.6 static void clut(const skcms_A2B* a2b, F* r, F* g, F* b, F a) { ^~~~ workdir/UnpackedTarball/skia/third_party/skcms/skcms.cpp: At global scope: workdir/UnpackedTarball/skia/third_party/skcms/skcms.cpp:2645:1: internal compiler error: Segmentation fault is caused by the clut() function still inlined for gcc. Patch makes this go away by leaving clut() with external visibility, thus getting gcc to outline it. Original Google hack with __attribute__((noinline)) alone appears insufficient. Change-Id: I8a566994ac815ae480ef1ce1b80c4fb59bef2f92 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92094 Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-04-10prefer DirectWrite for Skia's Windows text renderingLuboš Luňák3-0/+91
Change-Id: Ibfb6206751126def10905bb22effbe1a947cd6d6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91968 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-04-07optimize bit depth conversions to/from Skia where possibleLuboš Luňák2-0/+24
Skia has an optimized function for RGB->RGBA conversion that we are going to do often because 24bpp is the most common LO image format. The function is private, so patch that. Also optimize 32bpp->8bpp conversion with gray palette. Change-Id: I48b06f80d5ca9e1c8e3ee51da61e87541bd83d5a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91768 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-04-06do not build OpenGL support in SkiaLuboš Luňák4-66/+49
We currently do not use it. If somebody wants to add support for that, you're welcome, but until then there's no point in building this. Change-Id: Ia714a6babdac1824e6cca3438794a0945e175c14 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91746 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-04-06update Skia to chrome/m83Luboš Luňák7-76/+41
Change-Id: I350cbdf753f3d6f61623e384c4446c9c6890f041 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91745 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-03-31build Skia on Windows with UNICODE setLuboš Luňák3-0/+37
Skia uses the Windows generic macros that map to the ANSI *A variants or the unicode *W variants of functions/types, but in LO code we mostly use explicitly the *W variants and do not set the UNICODE define. So build Skia with UNICODE and explicitly use *W API in SKia's API that we use. Change-Id: I689797b30a412820f97d9ce88e9fe078ead2cf76 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91376 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-03-27fix LOGFONTA/GetObjectW() mismatch and remove Skia HFONT hack (tdf#131426)Luboš Luňák3-144/+30
The GetObjectA/W() functions are type-unsafe, and since we #undef GetObject I accidentally used GetObjectW() with LOGFONT that was LOGFONTA. This caused the font name to be broken, which made Skia use a different font. This means that Skia doesn't actually need the HFONT passing hack. Change-Id: I67b8d18fef6a92f8839b1652e051da96d01c3a4e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91202 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-03-20Missing include (Windows --disable-pch; for HFONT)Stephan Bergmann1-1/+10
Change-Id: Ia1dcd0d6b9f66517a6c2fe0186ed77e007677261 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90800 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-03-18(do not) use SK_GAMMA_APPLY_TO_A8 also for Skia text on WindowsLuboš Luňák2-0/+29
This is the Windows variant of the SK_GAMMA_APPLY_TO_A8 disabling, again I don't quite understand why we need to disable this, but with this patch Skia text rendering on Windows seems to be pixel-perfect when compared with the VCL gen backend. Change-Id: Iafc1e6353430e695dafa67d19eefd968d4f02ae2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90696 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>