summaryrefslogtreecommitdiff
path: root/vcl/inc/skia
AgeCommit message (Collapse)Author
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-14add unittest for SkiaSalBitmap copy-on-write data sharingLuboš Luňák
Change-Id: I2e331785d49c55116bf9cb893be25da1067df8ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104283 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
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-10-07try more to match Skia's alpha type for source and destinationLuboš Luňák
This is an extension of the other recent commit, matching alpha type is faster, and knowing the content is opaque should also allow more optimizations. Change-Id: I632d3f50e3f4729a64403c3c3ed1b79d63f0c5dd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104046 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-10-06loplugin:const* make some params and methods constNoel
Change-Id: If7fbb25037343e18081a8ee7064840d75e9a45a7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104010 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-05make it possible to accelerate AlphaMask::BlendWith()Luboš Luňák
If SkiaSalBitmap has the data already on the GPU, then without this the pixel data for both bitmaps would get read from the GPU (which is somewhat expensive), the operation would be done on the CPU, and afterwards quite likely the result would be sent to the GPU again. Change-Id: Ic6b7bf08b30e7083f6099eb66a45a82ebb54f326 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103888 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-10-04clean up handling of erased state in SkiaSalBitmapLuboš Luňák
So that e.g. ResetToSkImage() does not keep the erase state. Change-Id: I67e15c7f26c804437b15c394bf1aa4bbc38dfed1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103887 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-10-02add operator<< for SkMatrixLuboš Luňák
Change-Id: Ib3b0cd624e52ffcd765bb2ac48cafd6abfc476cb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103744 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-10-01add CppunitTest_vcl_skia to do Skia-specific testsLuboš Luňák
Change-Id: I7b5c1637aaf0fc070391f08800cd44308b4db0b6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103710 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-30make OutputDevice::Flush() also flush SkiaLuboš Luňák
Skia uses an idle timer to flush buffered Skia drawing. This has the problem that if there's a lot to do, the actual drawing to the screen may become starved and not update. Fortunately there's OutputDevice::Flush() that is called e.g. during Impress animations, so make that also work for Skia, which should make things somewhat smoother. Change-Id: Ia8629e63dc7d7a2d7200c033bc2dc2c51f6caf0b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103675 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-29disable VSync for Skia/Vulkan on Linux/nVidiaLuboš Luňák
It causes freezes. This can be changed later to a blacklist of older drivers once fixed drivers are actually available. Change-Id: I6cc996aee2ae69d5c8fdd9eb5f9f336683350485 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103554 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-29ensure SolarMutex is held for SkiaZoneLuboš Luňák
This is simply being lazy and requiring the mutex held for all Skia operations. With the effort to verify things it'd presumably be possible to make the code thread-safe. Change-Id: I748dbf2d5af66dcd140b5a9d6d57e9d848babf0e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103564 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-25simplify clearing all data in SkiaSalBitmapLuboš Luňák
Change-Id: I5e53b70bca651493a5bf449ca41a568e2a72b683 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103304 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-23detect and fail immediately on failed Skia allocations (tdf#135952)Luboš Luňák
The problem with tdf#135952 is that the PNG export dialog can lead to requesting an absurdly large image, which leads to allocation failures. Some VCL backends such as headless try to cope with this and bail out, but they often crash anyway, since at higher levels of LO code nothing checks for these corner cases anyway. And even if nothing would crash, this can lead to silently losing data. So I've decided to directly detect such cases and fail hard and early. Change-Id: I5277a65c794116206de8280faf22ff897daa2f56 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103171 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.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-08try harder to not duplicate large memory usage in SkiaSalBitmapLuboš Luňák
This is an extension of a9f68d9d9ae8d7c8f79152055795044993b252ea. Try also to drop the image if converting back to buffer, and also try to do the same with the alpha image if the conversion is simple. Change-Id: I88f6f9d37a1e527c2d6c083ee9744959571534ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102209 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-08make SkiaSalBitmap debug also log bit count and palette presenceLuboš Luňák
Change-Id: I68143ae7ed1c55b035999ea5babec6e1b3aa72d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102210 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-07improve debug for erased SkiaSalBitmapLuboš Luňák
Change-Id: I1e1edafc7b9daf5748e22846ca5807613f779b2d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102167 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-09-07increase Skia image cache size to 64MiB (tdf#136244)Luboš Luňák
16MiB was enough to hold just one 2000x2000 image, which is almost the usual screen size. Change-Id: I8fd02101cd2a18ddb89500d555d5c2f051fdb81f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102069 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-04ignore fully opaque alpha bitmap for SkiaLuboš Luňák
This avoids some more expensive operations (if using CPU) like SkBlendMode::kDstOut for hacks like 9ff0cd1f6b2200940ac51e580809e2a17c4b9550 that just set a fully opaque bitmap as the alpha. Change-Id: I446efc482d7bb13e899bf8b352e13fce6b5f9176 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101896 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-08-05Silence loplugin:staticmethods when the definition involves preprocessingStephan Bergmann
...to help avoid false positives. (Another option to silence such warnings is to add (void) this; to false-positive function bodies, but this new approach may be more natural in certain cases.) Change-Id: Ie6ea908730c596dbfb62ff42ae60dbd0a00a8fc9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100152 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-29allocate bitmap data buffer on demand in SkiaSalBitmapLuboš Luňák
And also make sure mScanlineSize is always correct, which it seems like it possibly might not have been the case (the delayed scaling makes it a bit complicated, as the internal scanline size is based on the internal bitmap size mPixelsSize, not the externally reported bitmap size mSize). Change-Id: I0d6cc2fca27ffa1c3accc13b38c8c01b5ffc8ba0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99680 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-27do not use VCL scaling algorithm from SkiaLuboš Luňák
The only threaded one is "Super" (i.e. the default one), and Skia at a comparable quality seems to perform better. And the code is simpler too. Change-Id: I366197fe1a033c1f7a5f5c7f9fdcc00bff74dc11 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97278 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-22convert properly SkiaSalBitmap to WinSalBitmap (tdf#133152)Luboš Luňák
The code didn't account for topdown bitmaps. Change-Id: Ia326834cfd6d2d022579fdde24828f7e0a8d8b3e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94643 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-05-15do not cache SkBitmap in SkiaSalBitmapLuboš Luňák
It doesn't make much sense anymore to keep it around, it's now used only by GetAsSkImage(), which is only called from GetSkImage() and GetSkAlphaImage(), and it's unlikely one SkiaSalBitmap would be used both as a bitmap and an alpha mask. In Vulkan mode this should save the memory (in raster mode the memory is shared by the SkImage). Change-Id: I5818a462aca85906f2e82cd951b6241d954723c6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94228 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-05-14cache results of Skia's drawTransformedBitmap() (tdf#132438)Luboš Luňák
E.g. scrolling in Writer with a huge image inserted requires scaling down on every paint, so cache the result if it's expensive. Change-Id: I9db040eab47e0e9d7fd416ad064caf0301d346fb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94118 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-24make SkiaSalBitmap discard cached data of incorrect size (tdf#132367)Luboš Luňák
Performing the delayed scaling for the bitmap data could keep around cached mImage with a different size. Which theoretically could be kept around and resized later, but the bitmap data scaling finishes the delayed scaling by discarding all the data about it (scaling quality), so the later resizing wouldn't know how. Change-Id: I6a817d87becd44214f0f4db0755731b6e4ae1409 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92846 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-10prefer DirectWrite for Skia's Windows text renderingLuboš Luňák
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-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-07no gray conversion needed for VCL alpha hacksLuboš Luňák
AlphaMask doesn't need any conversion to gray, it's just enough to make sure the alpha channel bitmap is 8bpp. And the conversion is needed for the separate-OutputDevice-alpha hacks, where GetBitmap() gives non-8bpp bitmap for the alpha contents, but there all the R,G,B channels are the same, so just take red and avoid pointless conversion. Change-Id: Ib30fc8fa6d05067d582402ab2c0fcfb49a3742f2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91772 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-04-07avoid Skia bitmap->image pixel copying in raster modeLuboš Luňák
SkImage::MakeFromBitmap() shares the pixels instead of copying, so in raster mode this saves some work. Change-Id: I89aa86c269c4b4f24e305dec390ae0f80e2537da Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91769 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-04-07use delayed scaling in SalSkiaBitmapLuboš Luňák
This allows doing the scaling at least in some cases on the GPU. Pending scaling is detected by mSize (logical size) != mPixelSize (actual size of pixel data). Change-Id: I8adef13750c195fdbe48c9167737a0c31cda66d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91767 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-04-03loplugin:finalclasses in xmlsecurity..UnoControlsNoel Grandin
Change-Id: I8e942bf37c9173a01bef6e1403ca21f579e7f608 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91612 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-03-25make sure only VCL-Skia or VCL-OpenGL is enabled (tdf#131543)Luboš Luňák
The bug is most likely caused by some code checking only the OpenGL setting and doing something, even though the Skia setting takes precedence. So make sure VCL OpenGL is considered disabled if Skia is enabled. Since isVCLOpenGLEnabled() is called right before setting up the X11 visual, which is normally needed by isVCLSkiaEnabled() to get Vulkan info to check blacklisting, this also requires using a temporary Skia Vulkan context using the default X11 visual to avoid the dependency loop. Change-Id: I2d9d9e81ab4ed5021b5f42e3c272dcd10fd32cce Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91044 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
generated by cgit (git 2.34.1) at 2024-07-02 04:07:35 +0000