summaryrefslogtreecommitdiff
path: root/vcl/inc/skia/gdiimpl.hxx
AgeCommit message (Collapse)Author
2024-05-10loplugin:ostr in vclNoel Grandin
Change-Id: I5b6ee5bda0c5ff69d297f7f8e87d4c3f3d21791c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167470 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-02-26tdf#143148 Use pragma once instead of include guards in vcl and xmloffanish.deshpande
Change-Id: I317da0a6f626e8ddb3f090099347b130e99ff2a2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163856 Tested-by: Jenkins Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2023-07-31all drawPolyPolygon variants return true nowCaolán McNamara
since: commit 4998de76ed1da4039e30718941d50d6f1dfe4f82 Date: Sun Jul 30 07:40:48 2023 +0000 tdf#156230: Drop freshly unused GenPspGfxBackend Change-Id: I7fc2a068f807777ed392c5d58772d130bf7f51c8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155076 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-07-10update skia to m116Noel Grandin
(from m111) SK_SUPPORT_GPU is now SK_GANESH GR_OP_ALLOCATE_USE_NEW was removed in skia m111 commit dd8f8ed3848cbe2032edc7ec08ef648a23e28ad9 Author: Mike Klein <mtklein@google.com> Date: Thu Apr 22 12:17:33 2021 -0500 clean up defines that do nothing the fast-png-write patch was removed. The underlying helper function we need was removed in commit 0ec4c84abd0b578a5c792b04b56653cbc325530e Author: Kevin Lubick <kjlubick@google.com> Date: Thu Apr 20 14:46:28 2023 -0400 Remove SkImageEncoder and SkImage::encodeToData So I updated our dump() function in SkiaHelper.cxx to use the new Skia API. The constexpr-template patch seems to be superceded by skia changes. SkOpts: :hash_fn has been replaced with SkChecksum::Hash32 commit 657ed9cf2379a950b925cb2aba7c85d6e1dd36ed Author: Brian Osman <brianosman@google.com> Date: Tue May 23 12:40:12 2023 +0000 Reland "Replace SkOpts::hash/hash_fn with SkChecksum::Hash32" The SkDebugf function needs to be exported from the library since it leaks out to calling code via some of the headers. Change-Id: I80ace8f25e660fa7889d22ef90676f47264d866c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154223 Tested-by: Jenkins 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-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>
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-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-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-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-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-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-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-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-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-24build Skia with Metal supportLuboš Luňák
Change-Id: I7a9abde4101164af8c47433acfa35f4f9d3b3d04 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120907 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-05-24fix Skia Windows text renderingLuboš Luňák
This is quite some trial and error, but now it seems all CJK text rendering works properly. I tested tdf#136081, tdf#137907, tdf#103785, tdf#106295, tdf#114209 and tdf#141715. Change-Id: I40e893f66281b0a1a0e814feec3f782ceeb0c535 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115620 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-05-24fix font scale width handling for Skia/X11 (tdf#136081)Luboš Luňák
We get width+height, for vertical text width is the font "height". This means we need to use two different fonts, one for "normal" glyphs and one for vertical glyphs. Change-Id: I9d190fc28286055a18c3d5c3ec75515c7c1d4373 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115618 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-03-01generic Skia workaround for VCL sending empty size (tdf#140288)Luboš Luňák
There have already been commits to handle this, but the case of getting the wrong size the first was still broken (or was fixed in the past and got broken again). Try to be generic by forcing these to be always considered to be offscreen and force non-zero size there. Change-Id: Ie366a296f7f6645333630fa31e9fe18d54c7fba8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111528 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-02-24add additional 0-1 alpha argument to DrawTransformedBitmap()Luboš Luňák
This allows the VCL backends the apply the extra alpha transformation as it sees fit, rather than it being done manually elsewhere (and even if the backend doesn't implement it, at least do it in one place in the function). With the document from tdf#136223, going from slide 2 to slide 3, this easily saves 10-30% of CPU cycles. As an additional bonus, using AlphaMask::BlendWith() rather than AlphaMask::Replace() makes edges of shapes noticeably more smooth. Change-Id: I036dc9b887d6def0c7cdad3982becabdc7cd5206 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111247 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-02-24simply use drawTransformedBitmap()Luboš Luňák
At least with Skia this is faster than GraphicObject trying to handle it manually, even in raster mode. Change-Id: If77d108751f5621878d4ea87a996c2ea0253d111 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111246 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-11-17tdf#138022 Skia don't recreate empty surfacesJan-Marek Glogowski
Skia can't create empty surfaces, so the recreation will hit the std::abort() in SkiaSalGraphicsImpl::createWindowSurface. Origin of the backtrace is some queued Resize event, which will hit this a few times via SkiaSalGraphicsImpl::checkSurface. This feels a bit like tdf#130831, where VCL tried to track damange for an empty Qt image... Change-Id: I75e22c987ba633e7a403541db8d580df33c68964 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105963 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-11-14remove SalPointNoel Grandin
<caolan> that "SalPoint" doesn't really seem to to have a purpose except to highlight that "Point" is assumed to use LONG under windows and can be passed unchanged to those windows drawing apis <caolan> so I guess remove SalPoint entirely, use Point instead, and convert to "POINT" under windows ? Change-Id: Ic15a7f4516e2075a228fa65cac4e8494d5b3abaa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105634 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-19use tools::Long in vclNoel
Change-Id: Ice1055021e8568634e9a66ba89d3bb4ef4e731df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104522 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-08track dirty areas for Skia drawingLuboš Luňák
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-09-25xor drawing done twice in the same place should be a no-opLuboš Luňák
This extends the VCL backend unittest to check for this, and also fixes Skia to handle that properly. This makes tdf#132241 slow again. The problem there is that it does drawGradient() with xor enabled (for whatever strange reason), and since Skia does not implement drawGradient(), it gets drawn using polygons and their bounds overlap, causing applyXor() after each operation again. Implementing drawGradient() will handle that. Change-Id: Ibea433ad95f8c6d53049f4a49295e57a5aec184f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103280 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-25draw linear and radial gradients directly with SkiaLuboš Luňák
Change-Id: I592fd5d823d70c6ca01e90e96a30fb6925f63545 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103282 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-09-23if allocating Vulkan surface fails, fall back to Skia raster surfaceLuboš Luňák
Occassionally there may be very large surfaces, such as in tdf#135952. Try to fall back to raster, which is more likely to succeed, given that it uses system RAM instead of video RAM. Change-Id: I81994b174e5e52066eacc5f8778e9469b042f9c8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103170 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-07do not queue up too many Skia image drawing operations (tdf#136369)Luboš Luňák
The document tries to draw a larger number of tiny bitmaps, which results in Skia trying to allocate many tiny GPU images, which slows it down (something quadratic there?) and it may eventually run out of memory. So force a flush if there are too many such operations unflushed. This is somewhat similar to what was done in the past by ad3580df085b3a3d66eb73cae997ea5ca178ccc1 . Change-Id: Ib0309ea9c7ac6c80d69ceed2922e885a2aa7f2d8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102166 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-08-26optimize polygon merging in Skia (tdf#136139)Luboš Luňák
basegfx::utils::mergeToSinglePolyPolygon() can be an expensive operation when many polygons are involved, and the code was calling it for every new polygon, which is actually not needed. Simply merge all the collected polygons just once before they need to be drawn. Change-Id: Id29d5dd5647d262b2cdfe9963f8d4e2ace844b66 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101384 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-08-26update Skia to chrome/m86 snapshotLuboš Luňák
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-07-16merge needlessly split polygons back in Skia drawing (tdf#133016)Luboš Luňák
There are places in LO code that needlessly split polygons into a group of adjacent polygons. These should theoretically result in the same, but only if antialiasing is not used (where Skia has a problem and according to Skia developers that's not really Skia's fault). So whenever a possibly problematic polygon is asked to be drawn, delay it and try to merge it with followup polygons back into one polygon where those needlessly created problematic edges do not exist. This is indeed just a hack and those problematic places should be fixed, but oh well :/. Change-Id: I1b03fe7c2f5e8c962b0dcb8962196b7fea090146 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98887 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-07-16use consistent Skia pixel position adjustments (tdf#134346)Luboš Luňák
What happens in tdf#134346 is that the same shape was drawn twice, once using drawPolyPolygon() and once as an outline using drawPolyLine(). Those had different offsets, so with AA enabled the tiny difference could be actually visible. Be more consistent with how the pixels are positioned in float coordinates. Change-Id: Id852fef70e7bd829ff0108a86d1ebee29c300e3a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98745 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-07-01optimize Bitmap::Erase() for Skia by delaying the erase (tdf#134363)Luboš Luňák
Tdf#134363 causes OutputDevice::DrawTransformBitmapExDirect() to create a huge 1bpp bitmap as mask, and Skia code then tries to convert all the bits to a format Skia would understand. Which is wasteful, as SkShader with the color given will do the same task much more efficiently. Change-Id: If0bba16f56fed9c3720be801b25a1e703054ed8d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97488 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-06-26use Skia's SkShader for blending bitmapsLuboš Luňák
It turns out it's sometimes more efficient to use SkCanvas::drawPaint() with SkShader::Blend() used to blend bitmaps together, rather than manually creating temporary SkImage for the blending. This way it saves memory and it also performs faster e.g. for tdf#134237, where when zoomed it processes only relevant parts of the images instead of blending a whole enlarged image). Sadly in raster mode it is sometimes still faster to cache the image (e.g. with tdf#134160), so keep the caching there as well, for when useful. Change-Id: I887ae330907100c21a0d152783fcd7e8ef230355 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97238 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-06-25handle nullptr pointers in Skia debugging functionsLuboš Luňák
Change-Id: I2c500444f97f66b03cc0e0a27581ced4d1cfbf22 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97102 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-05-26use Skia to do dashed lines, no need to do it manually (tdf#130431)Luboš Luňák
Change-Id: Id5efe7227f3c2bcb5ef6f1b990327e72014e8c47 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94857 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-05-05fix line width in DrawPolyLine() with matrix (tdf#132498)Luboš Luňák
For backends that do the object-to-device coordinates transformation directly, it's necessary to also convert the size of line width. But simply multiplying it with the matrix can also rotate the line width "vector", making it e.g. negative. So don't use just the X coordinate, use vector length for the transformation, which is ok. In fact it doesn't even make sense to treat width as a vector, because a width simply is not a vector (and for this reason it's also not actually used). Change-Id: I1241c9cb29155df105170d568a879ebc32b11a5f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93203 Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Tested-by: Jenkins
2020-05-04remove old Skia text render methods that do not use Skia directlyLuboš Luňák
The cairo-based method on Unix and manual glyph handling way taken from GL on Windows should be longer be needed, now that using Skia itself for text rendering seems to work fine. This reverts more or less reverts the following commits: b1d3ef798a89d11b853c467fa9ce0fe6ed235735 5ac9a62f3a354db80837bdd1c95b763989b303bb 619959827003814053a5e9ec81acfd07b3aa270a 6f5c85daa0e5073d87d1d7699bfa59af159686ca ad3580df085b3a3d66eb73cae997ea5ca178ccc1 f109a1ac6fdf0c878d53dfea6fceffd93248608f 59205c742c43b4c456b69c3fd94e7fa35ff3eec0 Change-Id: Ib28b2469c7d6471c227bb2aa08d5485bb24c2fe1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93428 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-04-20batch Skia xor drawing (tdf#132241)Luboš Luňák
The code previously applied the xor operation after each drawing, but the bugdoc draws a large number of polygons in xor mode, so the xor drawing was done repeatedly. Do the xor drawing just once when leaving the xor mode. Change-Id: I6c8d1c2f01688dc957a0af75232ee9fb69fe5d1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92558 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-04-08fix/improve Skia debug messagesLuboš Luňák
CopyBits() wasn't reporting 'src' if it was different from 'this'. Put the 'O' for offscreen after 'G' or 'R', so that it doesn't look like 0 being part of the size. Add pointer value to the Idle instances debug name. Change-Id: I001f4265696ff2b15e0273b3ae0c3857b39e2a0a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91835 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-04-06update Skia to chrome/m83Luboš Luňák
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-18fix glyph rotation for Skia text rendering on WindowsLuboš Luňák
The makes the chart descriptions in tdf#114209 and e.g. Japanese from the document from tdf#126169 be rotated correctly, Change-Id: I09a739fea7629000f3f49e417531bc47ba99c68f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90610 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-03-18implement text rendering using directly Skia (X11)Luboš Luňák
The Cairo-based way reuses code that is used for OpenGL, but it's needlessly complicated, given that Skia itself is capable of text rendering as well. This requires a small patch for Skia so that it uses the FcPattern* we use for selecting a font. The rendering with this commit is usable, but visually the result is noticeably different, so this will need tweaks to the font rendering (TBD). Change-Id: I058c282307106c929ccc9faa7b2bddfabf0f0a2c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90580 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
generated by cgit (git 2.34.1) at 2024-08-05 21:18:35 +0000