summaryrefslogtreecommitdiff
path: root/vcl/skia/gdiimpl.cxx
AgeCommit message (Collapse)Author
2023-03-03Fix SAL_INFO dereferencing optionalsMike Kaganski
Change-Id: I6d8ec4cd481284a42db33bf85ec7770fbb89cf83 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148168 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-01-30Update skia to m111Noel Grandin
(*) Remove patches already upstream (*) Remove the skia_sk_cpu_sse_level_0_by_default.patch.1 patch and rather set that define via -D parameter, because that is how the skia BUILD.gn seems to do it. (*) I hand edited the PCH file, because running the update_pch script failed for me. Change-Id: I1fd175b9f63f8d2792a1876e4ece03fe92fb5374 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146251 Tested-by: Jenkins Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-26tdf#147342 Notify Skia that the window's backing properties changedPatrick Luby
Change-Id: I4185a240a2ca6df1c92e86ff9950f86234d4ace8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146142 Tested-by: Jenkins Reviewed-by: Patrick Luby <plubius@neooffice.org>
2023-01-25Revert "Update skia to m110"Stephan Bergmann
This reverts commit aef70869b0fae3001648ec2a2651ffc9c507678f plus follow-up 4172fcb7514ff8a9e9740ff0939e9a2f611edbce "Fix no-pch Windows build: missing include". It caused my Windows build `instdir/program/soffice` to immediatley fail with > skia\include/core/SkRefCnt.h(62): fatal error: "assert(this->getRefCnt() > 0)" > warn:skia:10572:7804:external/skia/source/SkMemory_malloc.cxx:32: sk_abort_no_print on start. Change-Id: I751f83eda28d9a5a8f9dd4b2429389906ffce983 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146132 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-01-25Update skia to m110Noel Grandin
Removing those bits of the patches that appear to have been upstreamed. Change-Id: Ia7683c26af4c622ca4fccb828df023ae30e724a6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146069 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-06use std::optional for SALCOLOR_NONENoel Grandin
instead of re-using an actual real color value, because it will totally not work when I convert vcl to use alpha instead of transparency Change-Id: I01f043e0b65ffd852989dfe28f2b9d5a43c9c3d7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145075 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-05Related: tdf#152703 Prevent possible hang when live resizing a windowPatrick Luby
Application::Reschedule() can potentially display a modal dialog which will cause a hang so temporarily disable live resize by clampiing the window's minimum and maximum sizes to the current frame size which in Application::Reschedule(). Also, eliminate flickering during live resizing of a window when using Skia/Metal. When in live resize, the SkiaSalGraphicsImpl class does not detect that the window size has changed until after the flush has been called so call checkSurface() to recreate the SkSurface if needed before flushing. Flushing had to be moved during [self windowDidResize:] to eliminate flicker. Flushing in [self displayIfNeeded] does not eliminate flicker so apparently [self windowDidResize:] is called earlier. Change-Id: Id3de838d2e17fee85cb583b6c4e862b571d47142 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145053 Tested-by: Jenkins Reviewed-by: Michael Meeks <michael.meeks@collabora.com> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-05-21update Skia to chrome/m103Luboš Luňák
Change-Id: I35f1ca3fc703dbf31c68f4b145344b23029a156d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134688 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-05-04vcl : avoid recursive call if skia context creation failed.Arnaud VERSINI
To avoid this bactrace : https://crashreport.libreoffice.org/stats/crash_details/4d1984f3-3352-49fa-8569-ebf6994ed216 Change-Id: I45ae8b56191c546c551ccaf48d5ab27a20b8e0e6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133662 Tested-by: Jenkins Reviewed-by: Arnaud Versini <arnaud.versini@libreoffice.org>
2022-02-03handle graphics test specially in backends too if neededLuboš Luňák
The backend test unittest already needs some special handling (such as not smooth-scaling in Skia backend when in HiDPI mode), but graphics test were failing because the name of the unit test was used for detecting whether to do special handling. Change-Id: Ieb23915f1eeafc13c921de06475cb761dc4c485f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129292 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-12keep positions as DeviceCoordinate within SalLayoutCaolán McNamara
Change-Id: I20bbb0e252ffd09901f587599430e715dbe977b3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128300 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-01-12reduce explicit Skia flushingLuboš Luňák
The docs say that Skia handles this itself, and with Vulkan excessive flushing may show up in profiling in some cases, as it's apparently a non-trivial operation in GPU mode. Remove even the two workarounds, I cannot reproduce the problems anymore, so let's assume it's been fixed in Skia. But still keep the flushing after a certain number of operations, as too many pending operations still may overload Skia (or Vulkan?), besides tdf#136369 I can also reproduce it while loading bsc#1183308 which does a large number of tiny VirtualDevice's and does GetBitmap() on them. Also change the counter to be global, as we use just one Skia drawing context. Change-Id: I48b96c2a59f8e1eeef3da154dbe373a37857c4be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128293 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-12-06a large but clipped image may still be cached from a previous callLuboš Luňák
Canvas apparently likes to redraw only small parts of the background, which means that there may be repeated scaling of clipped parts of a large background image that are considered too clipped to be cached, but even the drawing of the clipped part may add up to be costly in the end if done often. Refusing the caching only after checking whether the image is possibly cached may avoid some of the drawing in case there was an initial drawing that wasn't clipped and thus generated the cached image. Helps a bit with e.g. tdf#136223. Change-Id: I4de6164940ec7a06fb6ae2f504907b4fa076f1d4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126412 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-12-04only bilinear+mipmap for Skia/raster to-screen drawing (tdf#146024)Luboš Luňák
The code already tries to hide the cost of the high-quality bicubic scaling by caching, but there are still cases where there's too much scaling done. Since this is only drawing to screen, use only bilinear+mipmap scaling in raster mode, which should be good enough (it's what the "super" scaling VCL algorithm for BmpScaleFlag::Default does as well). Change-Id: I75c86932e097411422dc1ef5e0534059dbf11ff8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126326 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-30fix Skia copyArea() not coping with coordinates outside (tdf#145811)Luboš Luňák
Apparently the call is expected to handle even copies that are partially outside of the area, e.g. window scrolling seems to do this occassionally. Change-Id: I9a06c047f00d6b5b920d61f577baa9181bdc5a2b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126147 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-29implement xor drawing directly using Skia (tdf#141090)Luboš Luňák
Up until now this has been implemented like in almost all other VCL backends by manually xor-ing pixel values. But that required fetching pixel values from the GPU in Vulkan mode, which is relatively slow. Since some time Skia now has supported writing custom blending modes using the SkBlender class, so it's now possible to drop the hack and support xor drawing directly using a blender that does the operation. This should be both faster and simpler. Change-Id: Id751d0ed4034852ce68697ecf56cc6dfac95307f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126051 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-29remove Skia kDifference workaroundLuboš Luňák
I thought it was a driver problem, but now I'm actually not sure, as I cannot reproduce it anymore and I don't know if it was a driver update or Skia update. Either way, this works now. Also switch to kExclusion, because the end result is the same, but this formula is simpler (to understand primarily, the performance is going to be probably the same). Change-Id: I6ced098ca4a3361cf98d3f9b32968c128eb9f299 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126050 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-22handle filling and stroking at the same time if possibleLuboš Luňák
All tests still pass, so the end result should be the same, but this way it's done in one call. Change-Id: If5da34837a45ad600ae30568e4ba7651ac5838bf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125644 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-22move code to helper functionsLuboš Luňák
I'll want some common extra functionality there later. Change-Id: I249f9ca4662fc8e8d52c58b1bd33293f363464d8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125643 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-19Drop F_PI1800/F_PI18000, and unify deg2rad/rad2deg conversionsMike Kaganski
Change-Id: Ib89b00c3dc8cd440e8a88906eea133becd1cef64 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125509 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2021-11-18Fix typosAndrea Gelmini
Change-Id: Idd21ee0026d8a36653f0fb25b350dae37315f603 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125336 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-11-18handle also curved lines for nojoin skia polylines (tdf#143837)Luboš Luňák
Change-Id: I2f5aa12eb656f6b337843d81a2a30de277dff7b7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125410 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-17loplugin:simplifyboolStephan Bergmann
Change-Id: Ifb7c6d8a4506808b5f56492e692ef7172a367e26 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125344 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-11-16fix drawBitmap() unittests with Skia/HiDPILuboš Luňák
Force non-smooth scaling to get exact pixel values. Introduced in 6792e6e5e49d11a54256b75c4c5a476bb2f10b4a. Change-Id: Iec2633e9ef8e930688c95ceb1037696456f344f5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125312 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-16try to avoid scaling bitmaps twice in Skia when drawingLuboš Luňák
The scenario is that something scales a bitmap and then asks for it to be drawn (possibly drawn scaled again). One example is OutputDevice::DrawBitmap() subsampling the bitmap that according to c0ce7ca4884f7f6d1 is supposed to improve quality with headless(?) backend, but with Skia it's pointless and it breaks things like caching during repeated drawing, because then GetSkImage() will need to generate a new SkImage each time. Since Skia backend uses delayed scaling, these cases can be sorted out by checking the stored SkImage and using it if suitable, as the original image is as good as the rescaled one, but often it's better - it may be cached, sometimes the scaling operations cancel each other out (often the case in HiDPI mode). Change-Id: I0af32f7abdf057a3bdda75247d2dc374eaf1bc4b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125311 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-16make SkiaHelper::dump() available also in non-dbgutil buildsLuboš Luňák
They are just a set of small functions, and I sometimes need to debug optimized builds too. Change-Id: I6350476e8c7fef85460a88b9e3d56d02213764ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125310 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-16optimize Skia's copyArea() to copy less dataLuboš Luňák
Change-Id: Ia1cd0522643b58ea1be3ad974c1fc5f7fed657d4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125268 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-16don't bother caching bitmaps that prefer shadersLuboš Luňák
Change-Id: Ibc78371f9e2ba92470714847bb6a5b8b96d1037f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125264 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-16when caching bitmaps in skia, take into account HiDPILuboš Luňák
Since the image will be actually eventually drawn twice as big, cache an image that is twice as big. Change-Id: Iea0340cd92c102e453330723c797659c742feb63 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125263 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-16implement HiDPI support for Skia/Mac (tdf#144214)Luboš Luňák
The basic idea is the same as the 'aqua' backend, simply set up a scaling matrix for all drawing. That will take care of the basic drawing everything twice as large, which is twice the resolution. And then blit this data to the window, which expects data this way. Converting back from backing surface needs explicit coordinate conversions, and when converting to a bitmap the bitmap needs to be scaled down in order to appear normally sized. Fortunately I've already implemented delayed scaling, which means that if the bitmap is drawn later again without any modifications, no data would be lost (to be done in a follow-up commit). Unittests occassionally need special handling, as such scaling down to bitmap not being smoothed, because they expect exact color values. Change-Id: Ieadf2c3693f7c9676c31c7394d46299addf7880c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125060 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-12get rid of Skia's 'rasterhack' for Invert()Luboš Luňák
It seems that manually writing a shader that does the same as SkBlendMode::kDifference works fine even though the blend mode crashes e.g. on Windows/AMD. So get rid of the memory<->GPU conversions and use the shader as a workaround. Change-Id: I971deeeb98f40e5ffa90f6a8dd7b0b21ec491c1a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125101 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-12revert part of 'loplugin:flatten' in Skia codeLuboš Luňák
The automated code flattening may make sense in old spaghetti code, but this is new code, and it's structured the way it makes sense. Both those if's are logically just a part of a larger function and bailing out sooner is at least conceptually wrong (and the moment I add more code there, I'd need to revert anyway). Change-Id: Iddbd22166159429636196eb1545b008ef576036b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125054 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-12improve mergeToSinglePolyPolygonNoel Grandin
spotted by llunak. No need to take param by &&, since mergeToSinglePol does not actually need to modify it. Also flatten it a little. Change-Id: I2f5ade347db756e21ecb0a88c3935805268f5072 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125086 Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Tested-by: Jenkins
2021-11-12clean up SkCanvas before using the bitmap it's painted toLuboš Luňák
I think this is not strictly needed with raster bitmaps, but still, this is the proper way. Change-Id: If6ccf82cf633afefa5c043096ec01b5f3891dc0b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125057 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-12drop usage of SkSurface::draw()Luboš Luňák
It causes so many problems that it almost doesn't get used in practice anyway. Change-Id: Ie11042749d0cca998af45be1daee6f14bf9531f1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125056 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-12reduce copy&pasteLuboš Luňák
Change-Id: Ie37f96755f348316bb8d5129df925134943e7ace Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125055 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-10-21loplugin:flattenNoel Grandin
Change-Id: I3b4226a9d089ec9aedab95d96e50a068f57a76c7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123991 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-10-10loplugin:moveparam in basegfxNoel Grandin
Change-Id: I73414e94358114ff0d475f13855db8c4c493b6f5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123334 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-10fix Skia/Raster screen flushing on MacLuboš Luňák
There's no window context in that case, so check the surface, as other places do. A mistake from 234ed4bcd5c4b5b41467890b82c6ef. Change-Id: I7f9d97340ed30444cb151c1141f8cc3045bd6dea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121892 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-08-31reduce code duplicationLuboš Luňák
Change-Id: I31ee84be7ebee7f1644d7fd43bbc951abd2842d6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121328 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-08-31Skia's kDifference now seems to cause crashes also on AMD/WindowsLuboš Luňák
Change-Id: Ia60605407ba9f890db308301711f2d54bca92d56 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121326 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-08-26change some left,top,width,height usage in Skia to x,y,w,hLuboš Luňák
Change-Id: I26e0f1f1c9aef795b040a191ffa9b725280eb63e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121080 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-08-25use our own Skia surface when using GPU screen drawingLuboš Luňák
Previously the code called window context's getBackbufferSurface() once, and the repeatedly used it for drawing and then did swapBuffers(). This worked until version chrome/m91, now Skia requires that a screen drawing pass is calling getBackbufferSurface(), drawing to it and calling swapBuffers(). Since we do not always draw full window content and instead keep previous content, use a separate offscreen surface for that and for actual screen drawing just blit that to the screen surface. Change-Id: I36a5b3bb23a085936f4473a0e00d8e04c6b40dab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120966 Tested-by: Luboš Luňák <l.lunak@collabora.com> Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-08-24initial Metal support for Mac/SkiaLuboš Luňák
This also required changing SkiaSalGraphicsImpl to have sk_app::WindowContext as an internal detail inaccessible to the base class, since the Mac implementations cannot use it as is. Change-Id: I2424f0b887c79ee91c3bd0f1477b0745f9540247 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120909 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-08-24remove unnecessary separate SkSurface creating per render methodLuboš Luňák
SkiaHelper: :createSkSurface() already handles this. Change-Id: I2eba5ab7f53f212ab1d5c0b9366d07543ea97fc4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120908 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-08-24reduce skia realloc when drawing polygonsNoel Grandin
Change-Id: Ide65945b2baa01b78c954112cdbf35edc41e2f8c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120916 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit (git 2.34.1) at 2025-01-13 03:48:28 +0000