My previous change had two problems:
- It didn't handle correctly the case when something repeated,
such as dash-dot-dot.
- The rounding when setting lengths was a left-over from my first
attempt when LineInfo used integers and not floats.
Change-Id: I914241590b1ddec22df04c05dfe65e76e921ee52
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114940
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
basegfx::utils::applyLineDashing() is not as good as the actual
VCL backend dashing, and there are some rounding errors because of
all the canvas transformation matrices or whatever, which leads
to the drawing problem. So use LineInfo to carry the dashing
information.
As a part of this change, also make LineInfo use doubles instead
of ints. The use of transformation matrices means that the values
may be fractional and less than one.
Change-Id: Ia5ac7d266cab344b7137052c81fbd96c1ce28003
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114710
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
We can cast the PixelFormat enum to int for the same information
and we can use the enum to reduce ambiguity when possible.
Change-Id: I6ea648139465568cdeb12e5f5f75c7b609365bf4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113188
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
The original implementation had this peculiar idea of implementing
clipping using transparency, which slows everything down, because
contents need to be copied and then alpha-blended. Keep that only
for when edges of the clip are to be smoothed.
As a side-effect this also seems to fix tdf#115843 again.
The commit also adjusts the test for tdf#133477 to not rely
on the rounding introduced by the optimization from tdf#115843.
Change-Id: Iebae5996159cf9f17066205985c5b591abdae105
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111966
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
this just changes the Get/Set methods, the constructor and internal
representation of Color is not changed.
Change-Id: Idb6e07cc08bbaa5bd55b6bd4b585e648aef507b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109074
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
When FormControls are not in layout mode it would be necessary
to have real VCL ChildWindows in the client (usually the office).
While this is done in the office itself and thus the visualization
of FormControls (and their usage) is guaranteed, this is currently
not the case for existing clients of TiledRendering.
The big solution would be an API for the TiledRendering client
to get infos for FormControls and create these locally (what would
allow to have these editable/interactive and in the style of the
client system). As long as this is not the case, I add this fallback
to render the FormControls as content to the tiles to get them
visualized at all.
Change-Id: I0f7a5e7dc028373145a6a19b639ce82bdafc149d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107735
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
(In VisitVarDecl, filtering out AbstractConditionalOperator avoids an unhelpful
> ~/lo/core/vcl/source/pdf/XmpMetadata.cxx:63:32: error: replace single use of literal 'rtl::OString' variable with a literal [loplugin:elidestringvar]
> aXmlWriter.content(sPdfConformance);
> ^~~~~~~~~~~~~~~
> ~/lo/core/vcl/source/pdf/XmpMetadata.cxx:52:21: note: literal 'rtl::OString' variable defined here [loplugin:elidestringvar]
> OString sPdfConformance = (mnPDF_A == 1) ? "A" : "B";
> ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
)
Change-Id: I7d0410f04827d79b4b526752917c37d33cad2671
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104911
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(*) create a rewriting plugin to do most of the work, heavily
based on the fakebool plugin
(*) but there are still a number of "long"s in the codebase
that will need to be done by hand
(*) the plugin needs lots of handholding, due to needing to
add #include and update macros
Change-Id: I8184d7000ca482c0469514bb73178c3a1123b1e9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104203
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
A number of powerful functions using B2D polygons such as
OutputDevice::DrawPolyLineDirect() were used only if AA was enabled.
So e.g. dashing for an AA-ed polyline could be drawn directly
using the function, but with AA disabled had to be done manually
by a number of polygon operations. Which doesn't make much sense,
surely these powerful functions can also draw without AA if set so
(and indeed that's mostly the case). And DrawPolyLineDirect() even
had a flag to bypass the check.
So simply try to use B2D-based drawing whenever possible, AA or not.
The previous commit had already changed the naming of the AA option
to not include B2D in the name.
This seems to come from https://bz.apache.org/ooo/show_bug.cgi?id=88795,
which doesn't explain why AA only. There are other bugreports such as
https://bz.apache.org/ooo/show_bug.cgi?id=101491 and
https://bz.apache.org/ooo/show_bug.cgi?id=98289 that are related, but
there I cannot see any difference with this patch. And all unit tests
pass.
Change-Id: Ibb5938e8fff9b7452bac4bf12ed3e42fd3e5d645
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103354
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
This renames AntialiasingFlags::EnableB2dDraw to just Enable,
and the AntiAliasB2DDraw names to just AntiAlias. This is
in preparation for a second commit that will actually separate
the AA and B2D functionality of these flags.
Change-Id: I9cc215c5752dfabce41e00e19d9074fc8dc3d4de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103416
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
VCL's drawGradient() can handle them all, at least using a fallback
algorithm. And drawinglayer doesn't know which of them are handled
directly by the VCL backend used.
A catch is that the rendering of tdf#133477 is different, so
keep using drawinglayer for the affected gradient types until somebody
fixes that.
Change-Id: I1719c67c15752c6d1c3431ddfa797ac94d039555
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103376
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
This adds a divert for drawing of linear gradients drawing, which
can be implemented natively with a much higher quality and speed.
This also adds a implementation of drawing linear gradients with
cairo.
Change-Id: I8c39915c3579e6eb88cdce8ae4ac9694ffdb4957
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103374
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
This removes the only place that hadn't used transparent impBufferDevice
yet - in VclProcessor2D::RenderMaskPrimitive2DPixel. Not clearing the vdev
made it draw on whatever garbage was left there from previous paints when
the buffer was taken from maFreeBuffers in VDevBuffer::alloc, so since this
was also the only place left that didn't clear the buffer explicitly, this
makes the clear unconditional in impBufferDevice ctor.
Also this makes sure to clear proper rectangle in VDevBuffer::alloc, and to
clear mpAlphaVDev in OutputDevice::Erase.
Change-Id: I7c1c0cc510a92628f19020b3faf0c0cd81f5a599
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100674
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
When zooming in the bitmap can become huge, requiring a lot
of processing, most of it not being used.
Change-Id: I0a4907f5cf23ab7316fed8568924fe76c744b81a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97872
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Add initial color stack as an optional processor ctor argument,
so that it wouldn't be possibe to modify it after construction
from outside randomly (which could break the stack state).
Change-Id: I8aae4b806531fa61cc67def865297f5de1cf0755
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96684
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Create processShadowPrimitive2D function which uses the blur radius
from the shadow primitive to generate mask for the shadow bitmap.
Change-Id: Iba86bdbe1728153d866dd559a1b12eb5570ced51
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95859
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Since we need objects' bounds here, antialiasing them would make the
resulting non-fully-transparent areas thicker, thus making the effect
also thicker. Disable it here; also slightly increases performance.
We can't do that for soft edge: the effect draws all its children as
bitmap, so disabling AA would make all children areas unaffected by
soft edge to have worse image quality.
Change-Id: Ifc9a60ec7894bfe9d0209e04532c9ca0a1eb3867
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95096
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This allows UnifiedTransparencePrimitive2D to produce truly transparent image,
usable later in the stack - specifically by glow and soft edge effect.
Change-Id: I27e9bfbfb9c60856bc3fad1a483623c90d5cabff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94969
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
So the objects that were semi-transparent don't become opaque upon
applying soft edge effect. This requires that the objects are
actually semi-transparent, so that we can get alpha mask from bitmap
Change-Id: Ic4af9bea19e5e71139d3f065797583f7c7c78815
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95034
Tested-by: Jenkins
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
impBufferDevice now can create its mpContent with alpha; that is used
when painting, blending mpContent's alpha with mpMask/mpAlpha/fTrans.
That allows to paint to the buffer device and get actual transparency
of the painted objects in one pass, to process further (e.g., modify
transparency separately, or use it to get mask).
Required for subsequent soft edge effect improvement
Change-Id: If19c160581ce9a515d86222dd2fab06f746df2da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95030
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Luboš Luňák