Age | Commit message (Collapse) | Author |
|
At least Skia and OpenGL use POST_PAINT priority for flushing drawn
contents to the screen. Using the higher REPAINT priority here could
mean that actually showing the contents would not happen. Also,
at least with Skia+Vulkan, it seems that Skia could queue commands
indefinitely, eventually running out of resources.
Change-Id: Ia3969bad18d710b006325a0fba11dc318ff93786
|
|
Skia/Vulkan as the newer technology should be preferred, currently Skia
is not enabled by default, but that can change later. And this
should be consistent, otherwise the about dialog can claim OpenGL is
used while it's actually Skia that gets selected elsewhere.
Change-Id: I185feb231c28a119a1152e92afb54a1e8c41af6f
|
|
Code pretty much copy&pasted from the vcl/quartz version. Fixes
e.g. Writer marks showing paper corners.
Change-Id: I3c9d2ed00efe409abd0a730a6f7dc0ea2a31c90a
|
|
This is rare, but it may happen. Since now the code shared just one
GrContext properly, this is not really a problem anymore (and the extra
WindowContext creation shouldn't be hopefully noticeable either).
Change-Id: I50887b7512e778b70870690a3f672b27cc7f2d21
|
|
Change-Id: Ie46d7d89b9aa149f48617ccdbe3a8c492759880f
|
|
It appears that there are still some paths that do not expect
bitmaps to be truly 32bit, so better revert to the old safe (and
poor, complicated and inefficient) way of pretty much ignoring
the alpha channel in SkiaSalBitmap, and let BitmapEx handle
it by using an extra alpha bitmap.
Change-Id: I4318c05f4ceafc5de48e19eeae5efe2abed2ec69
|
|
I.e. those created with vcl::BackendCapabilities::mbSupportsBitmap32 set.
But there are quite possibly many more places that do not expect
that the Bitmap itself would contain alpha.
Change-Id: I83db37b3d346f42565f96b9bbf81c71b97b6bf8b
|
|
Change-Id: I61f082d8a8d8eead6c49bbf3da997462e7d9738e
|
|
Change-Id: I10ca633d31163c968b0010983132942a1823a3f6
|
|
Mostly warnings from the 'casttovoid' Clang plugin, which is rather
annoying here.
Change-Id: I3d69697143f690211cdd26d1b9a4c0efe9397197
|
|
Change-Id: I3ea06a872d5348f7681602a6d68ff69990f2cd7e
|
|
Since they are technically still two different rendering implementations.
Change-Id: I83c324b384b7acfcc84e729271d00b995327eec6
|
|
According to Tomaž that's a requirement and that is what the test
for it tests. This is easy to implement with additional clipping.
Change-Id: Ia54489e20ce58ae0624183f2989036e6938cd44f
|
|
Skia is now patched to be able to create also invalid
sk_app::WindowContext that will just initialize the shared GrContext.
And always use that GrContext, even for tests, because some tests
first create a offscreen surfaces and only later create windows,
which before this patch led to mixing GrContext instances.
Change-Id: Ic79c0719f98f6ac48527c2ea2a9a9a69412adeff
|
|
They already exist and are used by the unittest. And the TrackFrame
test actually appears to expect incorrect results (or otherwise pretty
much all backends implement the operation incorrectly).
Change-Id: I26867a2d1b0f01b5e836131932b422cb8823fb5b
|
|
Change-Id: I8986064e581fdb9876068ae3b9736b9716554fb6
|
|
Change-Id: I044a9a31af71c4c624f08a0813bc59472f4c728a
|
|
Change-Id: Ic446f6f85e5ebc2e50cb51a3ed1e732b8976a193
|
|
The previous approach of using multiple GrContext instances apparently
does not work, it's not possible to do drawing operations that
involve objects using two different GrContext's. So patch Skia to use
just one GrContext for our needs. See vcl/skia/README for details.
Change-Id: I2bd3d3c618bf7f8ff45b2f37cbd086d2289940aa
|
|
VclPtr is a smart pointer, but it does not clean up automatically,
ScopedVclPtr does.
Change-Id: If792111cdd489b1743a1bcf060b56c52a4aa79d5
|
|
Sometimes VCL and X11 (and thus Skia) will have a different idea
about what the size of a window is. Check for the mismatch and avoid
recreating if it wouldn't do anything.
Change-Id: Icf3ebba9589cc6f12612e5f280840346cb0edaeb
|
|
Having them the same can hide problems with them fixed up incorrectly.
And it also shows that drawPolygon() with line color unset does not
draw the right-most and bottom-most line, which is what all underlying
graphics systems do, so the test is kind of wrong and I've added
a compensation to make it visually correct (and match the checked
expected result).
Change-Id: I333f41210232c74ba55bd5c92ef5fda917ce3e59
|
|
Change-Id: Ifcf8d4d7814daf3631b159cc979f3b8a80052196
|
|
According to https://bugs.chromium.org/p/skia/issues/detail?id=9611
rounding errors may cause off-by-one errors, so compensate when
converting int->SkScalar in relevant cases.
Change-Id: I72a579064206c216c9f99adc7d7c2c57bbe567d6
|
|
Skia's sk_app::WindowContext can create GPU-backed SkSurface only
for windows, but we also use virtual devices that are not windows.
Fortunately, SkSurface can be created GPU-backed from GrContext*
and sk_gpu_test::GrContextFactory seems to provide it easily.
It is not completely clear to me what the rules are on mixing
SkSurface's with different GrContext* (see the comment
in SkiaSalGraphicsImpl::copyBits()), but it seems to work fine.
Change-Id: I8110b67c41ab092e0c4b6a0973d6bed8a408c4c1
|
|
Not much point in showing the FPS if there's an upper limit on it
and many backends can reach it.
Note that with SAL_USE_VCLPLUGIN=gen this needs also
SAL_HIGHPRIORITY_REPAINT=1 in order to get the maximum FPS.
Change-Id: I18705bae81585d46bcaad658cc0c0c2158d89c30
|
|
Change-Id: Ife21bbe0b86c3edd20e657da09c6e218fa4fced3
|
|
Change-Id: I59af62fa92903823eb7105d82157017e485ba0df
|
|
In order to be able to detect incorrect/missing drawing.
Change-Id: I18b3f05c1fdff69b461f22e984e0aef3c4ce3364
|
|
Change-Id: I061acb80294c3bd6b45bd60dbb32c9a906619ed0
|
|
Change-Id: Ia8cfa8ef855f85cc324bc811e26dcab83b50b1be
|
|
Change-Id: I9260e277b83f71ee06129802d8278f098796760c
|
|
Pretty much copy&pasted from other VCL plugins ... whatever is
actually is.
Change-Id: Ibdd5d6d2106f303127afbbde45d400d02a5de93b
|
|
At least the KF5/Qt5 VCL plugins passes fine.
Change-Id: I033ddf6ae9cc663729ca459cdc514dc0fa51ddc2
|
|
Change-Id: Ia6d5545ef088604f3fe104b00cc86a45d91f6559
|
|
Change-Id: Ie01c9dba1287495db9f176c1e1e25799e5f3e872
|
|
function is checkInvalidSourceOrDestination
Change-Id: Id3b5dc69a3949f01b5335a9bdf0ce0ad165adab1
|
|
Add an additional parameter to drawBitmap - blend mode, so we can
also use the same bitmap drawing code for blendBitmap.
Change-Id: Iaa0aff6724c6644d80056097e7477b31c8412b29
|
|
Change-Id: I83f33795bea5ed72f1f3269f30f64b1b24566538
|
|
This fixes drawing of non-closed polylines. Without this fix the
non-closed polylines an extra step is still drawn from the last
point in the polygon to the first one (as if the polyline would be
closed).
Change-Id: I0171aede3dc03f83b7dd8ae699e6b505b3fd4f7f
|
|
This forces a blending of an alpha virtualdevice with a BitmapEx
which has an alpha component. This tries a fast-path with using
blendAlphaBitmap in the backend and does blending manually and
slower if the fast-path is not available.
Change-Id: I7e45dc78ce3e61ede408aa8388802a193cbc577a
|
|
Change-Id: I74c428b9b31b89536e72d53e418fc11b3f7e4e32
|
|
This improves the quality of e.g. the logo in the about dialog.
Change-Id: Ie42ecc466068f979e5982d91616a8a2f80e26319
|
|
Change-Id: I3856aa76e0280f4798893e02efd2b458cd95e65f
|
|
This actually fixes a number of drawing problems (e.g. highlight
in popup menus), it seems the other code path is buggy.
Change-Id: Iea697f577d08d20e338224d5ff5b3bf7b653f8d1
|
|
Change-Id: I1cbda292155e251e2d0900f00f804f01238998ed
|
|
Change-Id: I2fa0853ba2593583a479747460f77f2ced67fd6a
|
|
It now passes BackendTest::testDrawMask, so it should be checked.
Change-Id: Ib3e1df03aefe6e9487737bec036a943377414735
|
|
These should get fixed, but no point in having tests that already fail
without breaking anything.
Change-Id: Ibfa48fc22a4be1d76924d61a7dc223a56f64244b
|
|
Apparently that is the rule LO code uses, seeing e.g. the last screen
in visualbackendtest.
Change-Id: I88da7e96df9748cc6ffb3fbb6901512f59210cab
|