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
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
As the comment in SkiaSalGraphicsImpl::destroySurface() says,
they may both refer to each other's data when being destroyed,
so try to handle that.
Change-Id: I44353ed9d1888f8e8d15d93cd2c66414adfd372b
There are two cases in WinSalGraphics::DrawTextLayout(), with and
without cached glyphs:
- Cached case DeferredTextDraw() gets data as BGRA with the glyph
drawn in white, it just needs to be modulated to the proper color
and drawn.
- Uncached case DrawTextMask() gets data as BGRA with A invalid,
it must be used as mask for the color to drawn, but without
the inverse alpha VCL idiosyncracy that DrawMask() handles.
Change-Id: I05dcec994df68d5986cd85cffa42a8f9f23c42c4
Now that SalBitmap::convertDataBitCount() has been fixed,
the implementation here gets rather trivial.
This breaks Windows text drawing, which uses drawMask() incorrectly
(to be fixed in the next commit).
Change-Id: I98f11c1bd4b1600bb5e03e570319d29b40daa27e
If the rectangle is empty, there is nothing to draw. This also avoids
problems with WinSalVirtualDevice::ImplCreateVirDevBitmap() calling
CreateDIBSection() with zero dimensions.
Change-Id: I3a56e64fc32cfb855443f4ab665d53604d724d9b
The mistake in SalBitmap::convertDataBitCount() made this function
have 2 different results depending on whether that function was
used by GetAlphaSkBitmap() or not. Now that that is fixed, it
works to just handle alpha normally here.
Change-Id: Iae99cbefcda0a963401baf362faaad0df12a468f
VCL sometimes uses inversed alpha, but this function should always
just convert the format and not the contents.
Change-Id: I85943cb8d9db6c09c57ccf8fa45e8a591db10e6d
Currently based on identifying the SkBitmap's by their getPixels(),
but this may need changed later since it's probably going to be
more performant to use SkSurface.
Also move the cache pruning out of AllocateTexture(), as that may
possibly remove elements that would be used by DrawCachedGlyphs().
Change-Id: Ide2de752f634593b97573667af49b7aa9ec1f47f
Polygon, PolyPolygon and PolyLine rendering taking point array is
diverted to the one taking basegfx::B2DPolyPolygon or B2DPolygon.
PolyPolygon and PolyLine is implemented with Skia, with bezier
rendering included. The one thing missing is taking the input
matrix into account.
Change-Id: Id675dddcef95d2279410f5987424c1de6863cbe6
Pretty much a copy&paste of OpenGL. There are no settings for choosing
which backend Skia should use, as the plan is that simply the "best"
one will be selected.
Change-Id: I44fa876ab85de98de482a6ed9f814024334686ce
Since VCL seems to often do a resize between creating
the SkiaSalGraphicsImpl and actually starting to draw, it's a waste
to create a surface that will be immediately destroyed again.
Change-Id: Ic1f67701042ccae2ad51cb9a3f8646b888f94cc4
This is similar to what the OpenGL backend does. Apparently the VCL
code can just silently resize the graphics without telling.
Change-Id: Ie7c2a7798e76ad598e9cdd1435d68ed03793c408
