This is similar to the previous Cairo commit. Fetching pixels
from the GPU is not as slow as fetching them from the XServer,
but this still can make a visible difference. And small surfaces
should not need fast GPU rendering that much, so hopefully this
improves more cases than it regresses.
Change-Id: Ida031b38cd1ce14ded464747c20a38c6d094c5a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128310
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
The (private :( ) document contains a large number of small shapes
for which VclProcessor2D::RenderTransparencePrimitive2D() gets
called, which results in GetBitmapEx() on the VirtualDevice.
And Cairo normally needs to do a roundtrip to the XServer to fetch
the content, which makes the rendering pretty slow. Forcing
image-based surface for small sizes of VirtualDevice actually has
better performance for the document, and the lack of possible
HW acceleration generally shouldn't matter for a surface this small.
Additionally drawinglayer's VirtualDevice reusing tries to reuse
even a large one when a small one is needed, so a hack is needed
to avoid that in this case, I couldn't find a better way.
Change-Id: I0f58659ab88165a6bd915f100fc3b1d4802a0fa9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128309
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Rather than make all the BasePrimitive2D classes bear the cost of being an UNO
object, we just wrap the top level BasePrimitive2D in this class when we need
to pass them over UNO.
This reduces the locking overhead when doing normal drawinglayer operations,
and reduces the size of drawinglayer objects and the cost of initialising
them, which shaves 5% off the load/display time of a large barchart.
Add new drawinglayer::convertPrimitive2DContainerToBitmapEx utility
method to avoid needing to convert to Sequence<XPrimitive2D>
Change-Id: I553eaa4c16ba016b098cb21f6c55f5008f0d9b53
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126487
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
from "append" to "visit"
The current naming comes from when I created this class as replacement
for passing Primitive2DContainer around and the naming was meant to
reduce code churn.
But now that I'm using it more, the naming is an impediment to
understanding the code.
Change-Id: I4ee0156c7ffb534eac64f1c05eac6b8c67c25ab9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126321
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
noticable since...
commit 894b4911ff
Date: Thu Oct 28 09:27:29 2021 +0200
pass DX array around using o3tl::span instead of pointer
but presumably a problem since...
commit 7939059069
Date: Tue Sep 14 15:28:33 2010 +0200
filled-tab-editeng.diff: Filled tab wasn't filled in shapes
n#564454
here I assume the right fix is to extend the DXArray (if non-empty) to
match the new length using the value of the initial entry of the old
DXArray
Change-Id: I36a6040c2d05e108c7c6f9cdab9a33557036cd22
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124528
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
so we get bounds checking in debug mode
Note that I cannot just pass around the std::vectors
involved because there is a place in editeng which
calls with a subset of a vector.
Change-Id: I5088a139593c27bf9cbe5d843ab4b0048ac6d508
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124330
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
I have moved the header file to include/vcl/rendercontext as this will
eventually be part of the RenderContext split from OutputDevice.
State and associated enums have also been moved to the vcl namespace. I
have also moved ComplexTextLayoutFlags into the vcl::text namespace.
Change-Id: I0abbf560e75b45a272854b267e948c240cd69091
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121524
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
This is a follow-up to commit 37a52d30bb
(tdf#144091 svx: fix unwanted blur of shadow from table cell fill,
2021-09-20), where it turned out that the original bugdoc was just a
special case of almost full transparency (80%), that's why avoiding the
blur fixed the problem.
A more general approach instead is to multiply the alpha or the cell
fill of table shapes and the alpha of the shadow itself. The end result
is the same (80% transparency) for the first bugdoc, but this gives back
the blur on the second bugdoc.
Change-Id: I63560e3a73473c70157ecee8365ec7154217f269
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122532
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Initial render support for shadows of table shapes were added in commit
a75bf43a8d (tdf#129961 svx: add rendering
for table shadow as direct format, 2020-12-02).
That already noticed a trick with the shadow of table shapes: the shadow
is generate from the cell fill and the border, but not from the text.
An additional trick is that when blur is enabled for the table shape's
shadow, then only the border should be blurred, not the cell fill.
In the bug document's case, the effective cell background was gray, with
a semi-transparent red shadow. We used to render cc0000 with blur and
cccccc without blur, now we correctly render cca3a3, matching
PowerPoint.
Change-Id: I7326a5f6254cf19b2d05181084c78e734ff7a7b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122349
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Reading 'rectA.IsInside( rectB )' kind of suggests that the code
checks whether 'rectA is inside rectB', but it's actually the other
way around. Rename IsInside() -> Contains(), IsOver() -> Overlaps(),
which should make it clear which way the logic goes.
Change-Id: I9347450fe7dc34c96df6d636a4e3e660de1801ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122271
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Tested-by: Jenkins
because I'm trying to track down a related heap corruption, and that is
much easier if the access to the array is checked by the std::vector
debug runtime
Change-Id: Ia665f5cebb7f14d88942e88b4b400ad3c28ef5d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121527
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
By pushing the work down to the vcl layer, which has much more
efficient ways of dump lots of copies of a single image
Change-Id: Ie83fa56828df91a23b4b29934360ad80d1793c3f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117162
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Remove dynamic_cast'ing to Primitive2D, expensive and unnecessary
<quikee[m]> noelgrandin: nobody is using XPrimtive that is not
derived from BasePrimitive2D in an extension ... mainly as it is
not even possible
Change-Id: I68224021f0fbc35fe2a973198ba78d2b41ea172d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120417
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...that were present ever since the code's introduction in
c6df405c6c "#i39532#", but cause
`instdir/program/soffice --headless --convert-to pdf` of doc/abi5309-1.doc from
the crash-testing corpus to fail under UBSan with
> drawinglayer/source/processor2d/vclhelperbufferdevice.cxx:278:64: runtime error: -3.77964e+18 is outside the range of representable values of type 'int'
Change-Id: Ieff00d6fe91e2ffef46876ef308351d3689c5ffe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120055
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
ViewInformation2D doesn't need to know anything about the Sequence
of PropertyValue that is used for parameters when constructing it
through UNO API. This can be done outside of ViewInfromation2D and
it doesn't need to be responsible for that internally inside the
ViewInformation2D. With this we get ViewInformation2D, which is much
simpler and isn't prone to YAGNI.
Change-Id: I3836237a1d26e38145b52136c3204931ae7c6b79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119721
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
We actually never use extended information when normally using
the ViewInformation2D. The exception here is when we construct it
from property values, where the unknown property values are then
stored into the extended information sequence and then later
reconstructed when we convert it back to a sequence of property
values. Just for that case we don't neeed to expose the extended
information to the outside and create it, as that is then a
implementation detail for the UNO use case.
I am also not convinced we need it when creating ViewInformation2D
with the sequence of property values - it certantly not expected
that we need to preserve the property values at all, but that is
something that needs to be checked.
Change-Id: I3b8d533cd412aac8b89ca2921738d6487be5cf45
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119720
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
/** If a value is a valid argument for sin(), cos(), tan().
IEEE 754 specifies that absolute values up to 2^64 (=1.844e19) for the
radian must be supported by trigonometric functions. Unfortunately, at
least on x86 architectures, the FPU doesn't generate an error pattern for
values >2^64 but produces erroneous results instead and sets only the
"invalid operation" (IM) flag in the status word :-( Thus the application
has to handle it itself.
*/
chart2/source/tools/RelativePositionHelper.cxx
Function name: RelativePositionHelper::getCenterOfAnchoredObject
From here: suppose it's related to the orientation of the chart << 2^64
chart2/source/view/main/LabelPositionHelper.cxx
LabelPositionHelper::LabelPositionHelper
Suppose: setup label position.
There won't be angles grater than 360º.
chart2/source/view/main/PlottingPositionHelper.cxx
PolarPlottingPositionHelper::transformUnitCircleToScene
Suppose: maybe disc chart orientation?
Internal angle should be safe.
chart2/source/view/main/ShapeFactory.cxx
ShapeFactory::getSizeAfterRotation
Suppose: rotate shape
Internal angle should be safe.
drawinglayer/source/processor2d/vclmetafileprocessor2d.cxx
Constant 100% safe
sc/source/core/data/documen4.cxx
bool ScDocument::Solver
Suppose: the tangent is being used as numerical derivative (Regula falsi algorithm)
So no impossible angles
scaddins/source/analysis/bessel.cxx
Filtered it out as bad imput
Change-Id: Ib348cca6ce13263d087b6731f93f58d8a15cc725
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118193
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
The size of the whole gradient is getDefinitionRange(), while
getOutputRange() gives the area of it to draw.
Change-Id: I85dd7fe51bcc9c332a6fb0e6748d5ac89266b910
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115923
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
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>
Kunal Pawar