MCGR stands for MultiColorGRadient. This change allows/
prepares adding multiple color steps to gradient rendering.
This is preparation work to allow rendering MCGRs in the
future. All places are adapted in a way that currently
no change of behaviour will happen. It will be the base
to get MCGR rendering/decompose for Primitives and our
internal/existing gradients working.
Change-Id: I28bbd7d10b8670042343ada2a66b5909d3d31bbd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146748
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Added and unified usage of a helper to create primitive
sub content easily, also for visibility checking of
primitives. Some smaller cleanups, too.
Change-Id: I3c4cd3e98e62b8cf7984351dbb0b154470fd8e3c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145908
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
We urgently should get rid of XOR paint, modern
graphic systems allow no read access to the pixel
targets, but that's naturally a precondition for
XOR.
While we can do that for the office's
visualization, we can in principle *not* fully
avoid getting stuff that needs/defines XOR paint,
e.g. EMF/WMF imports, so we *have* to support
it (for now - sigh)...
This makes this renderer complete from the minimal
to-be-supported primitives, too.
Change-Id: Ie8fa98b777de764af0babe969296a671ca5cc7ce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145739
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
...which happened to go largely unnoticed (the would-be additional overload, as
seen when including drawinglayer/processor2d/SDPRProcessor2dTools.hxx first
thing in drawinglayer/source/processor2d/SDPRProcessor2dTools.cxx, was just
never defined nor used), but caused
> drawinglayer/source/processor2d/SDPRProcessor2dTools.cxx(140,6): error: externally available entity 'prepareBitmapForDirectRender' is not previously declared in an included file (if it is only used in this translation unit, make it static; otherwise, provide a declaration of it in an included file) [loplugin:external]
> bool prepareBitmapForDirectRender(
> ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
with clang-cl
Change-Id: I9f338dd998b66fe3223af045206a423b016b93f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145696
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Added support to directly paint FillGraphicPrimitive2D, that
means object fill with multiple tiles/tiled fill. Note: This
may use not only bitmap data, but also metafile or svg.
The standard decompose creates one transformed bitmap/vector
data primitive per tile what is correct, but has some limits
(a) These may get many when tiles are small compared to
mask polyPolygon (performance/ressources)
(b) Correctness: when rendering in AA the common edges of
tiles will *not* sum up perfectly, but due to AA
multiplying when blending will leave ugly 'traces'
This direct rendering avoids both. It can use the D2D Brush
functionality to repeat. Additionally to the current
office it can also do that when content is rotated/sheared.
This may not be well known since for those fills the office
always keeps the fill unrotated (for historical reasons,
primitives can do that, but not vcl). To see it you may
convert a SdrObject to metafile and rotate that, so the
content gets rotated and shows that ugly gaps.
Also added a square-pixel step value for vector fills where
the default gets used starting from some size. The argument
is better quality for vector data fills while only a
limited number of tiles will be rendered.
Also added a buffered handling of the (old and ugly)
OffsetX/OffsetY to make that work, we will not get rid of
that soon.
Packed all of this into tooling (so started a tooling
collection for SDPRs target-system independent) to be able
to easily re-use all these preparations/tests in other
SDPR implementations in the future.
Change-Id: Iafacf4181e7c9e2d2b2e3b5cf1f7e4cdd0a43f0a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145466
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
All stuff used from MS with names starting with ID2D1* is COM
API stuff, so referenced and interface-based. I thought about
making this more safe since a while (shared/unique_ptr, ...)
but found no good way to do it.
Also did not want to use CComPtr from MS and expand the devenv
we need on win, so was short before doing an own small smartptr
class. Luckily I asked sberg and he pointed me to the already
existing sal::systools::COMReference which exactly does what
I need here - thanks!
Unluckily I now had to change a lot of code - sigh. I wish
I had known earlier :-/
This change contains the renderer completely adapted to using
that much safer and better ressource control.
Plus I added (even more) comments to try to make more clear
in many plasces what's going on, what is done and why.
Change-Id: Ia2aa3223d0e5f7ec6569cde176cec1fadcd921dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145142
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
just some partial pieces
export TEST_SYSTEM_PRIMITIVE_RENDERER=1
and the simple drawing shapes work
Change-Id: I3e01501a1cb21ec86d6fe8f5637a23e7358ffc86
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144632
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
(SDPR == SystemDependentPrimitiveRenderer)
Make D2DPixelProcessor2D directly render the added simple
Primitives
LineRectanglePrimitive2D
FilledRectanglePrimitive2D
SingleLinePrimitive2D
to use less ressources & get faster since no conversion to
Polygons is done. These are Primitives that *may* be handled
directly, but do not have to - I checked that the decomposes
do work before adding direct handling.
Change-Id: Ifa97c595c262d84a9889f92571b2c9909bcef0e0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144626
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Added three simple tooling Primitives:
(1) SingleLinePrimitive2D:
Just a Line from Point A to B with a BColor, decomposes
to a PolygonHairlinePrimitive2D (and to a PointArrayPrimitive2D
if only a single point aka A == B)
(2) LineRectanglePrimitive2D:
(3) FilledRectanglePrimitive2D:
Rectangles that support fill or line, gets decomposed
to maybe PolyPolygonColorPrimitive2D (if filled) and a
PolygonHairlinePrimitive2D (if line) or nothing if the
B2DRange is empty
NOTE: If using these despite being hor/ver aligned due to
their nature as B2DRange(s) (aka 'non rotated/sheared')
these may have to be transformed if the current
transformation context you are working in is rotated
or sheared, so *ensure* to handle these correctly if
you do handle them yourself. This is not needed with
the Polygon-based ones - that's why these are - and
stay - the common case(s).
Both are hairline primitives themselves, so are potentially
*view-dependent* (see comment in *.cxx and *.hxx). They will be
useful as very simple primitives for small renderers, e.g. to
avoid conversion from rectangles or just lines to polygons.
The more general Primitives are always the polygon-based ones,
so these new ones get decomposed to these (decomposition direction,
complex -> simpler). This assures that a processor/renderer has
minimally to support the polygon-based ones, but *can* use these
simple tooling ones directly if he wants to.
This will come in handy for future System-Dependent PrimitiveRenderers,
which I am currently working on one to offer as example - this leads
to identifying helpful upstream things that will come in handy in that
regard - like these ones.
Change-Id: Ie5039e6cfad6c9914c165cae6f8b59abecc38302
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144543
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
As promised at LiBoCon'22 I have finished an example
implementation of a System-Dependent PrimitiveRenderer.
It renders on Direct2D, so Win only. I chose this with
no special thoughts, did not even know too much about
Direct2D, so had to read quite some docu. Still managed
to do this in a view days.
NOTE: To make it run you need to switch off skia on Win
probably due to some global extra stuff done there (?)
The Renderer is in a new file (ca. 1000 lines) in the
drawinglayer libary. It implements all of the needed
primitives, so capable of rendering EditViews (Draw/
Impress complete, Writer/Calc in parts, interactions,
overlay, selection(s), etc.). It is used completely
as replacement of the VclPixelProcessor2D which is
not used in the patched version *at all*.
Just one primitive is missing:
- InvertPrimitive2D: Not needed much (hopefully will
vanish), could also be added
It is not in production state, mostly intended as a
demonstration how Primitives are intended: Render
*without* using an OutputDevice at all, directly to
the traget GraphicsSystem. It can (and should) be
used as pattern for other implementations.
NOTE: Inside the implementation you can do whatever
you want, all is allowed. Only rule is to visualize
the geometry defined by the Primitives.
This version does not need any buffer allocations to
render and is thus pretty fast (uses ID2D1Layer). It
also has no buffering, but that could easily be
added. The needed classes/implementations to buffer
system-dependent representations of data exist,
so doable fast for Bitmaps, Polygons and PolyPolygons.
It runs stable and fast, but still has errors, so
it is sometimes missing to render some stuff. I
would have to debug/finetune it further, but I see
this all as doable. It's far enough to be seen as
POC and example.
I also added a not-urgently-need-to-be-implemented
primitive, the UnifiedTransparencePrimitive2D, to
demonstrate how to do that: Add a handler for it
and render the defined geometry if you can do that
more direct/better than the decomposition.
The rough to-do list would be:
- add missing Primitives
- InvertPrimitive2D
- add buffering of
- Bitmaps
- Polygons
- PolyPolygons
- add TextRendering
- using decompose to PolyPolygons currently, but
looks reasonably good with PolyPolygon AA
- general
- polishing
- bug fixing
- stabilization(s)
- speedups by adding PrimitiveHandlers
- solve problem with TransparencePrimitive2D
- had to use drawinglayer::createAlphaMask
there, see comments
Made handling of TransparencePrimitive2D work, some fixes
and changes, too.
Still not happy with processTransparencePrimitive2D, it
uses drawinglayer tooling (createAlphaMask) to do it's
job. It works, but there must be a better way. It's
okay for demonstration/POV though
Tried hard in processTransparencePrimitive2D to directly
render the alpha channel to a Direct2D
ID2D1BitmapRenderTarget using DXGI_FORMAT_A8_UNORM.
It does work theoretically as it should, but I found
no way to directly paingt to the AlphaChannel. It
seems as if Direct2D *is* hard-wired to always
alpha-blend, there seems to be no control or mode
to *select* the BlendMode to be used. Since only that
small step is missing I keep that code in (see
bTryDirectPreparationOfAlphaAsBitmap).
NOTE: No idea yet, but testing shows that the direct
but not yet complete way is ca. 7 times faster.
I have now added PointArrayPrimitive2D, so only that
InvertPrimitive2D is missing.
I also added MarkerArrayPrimitive2D to make it more
efficient (marker bitmap gets converted only once)
and better looking (not AAed anymore).
With both added, grid visualization looks good and is
fast.
Added support for BackgroundColorPrimitive2D
Added BitmapBuffering for Direct2D. This is a little
bit more complicated, theoretically all ID2D1Bitmaps
are specific to the ID2D1RenderTarget they get created
for, so theoretically they have to be (re)created
every time the ID2D1RenderTarget aka OutputDevice
changes - argh.
There is CreateSharedBitmap though that
allows re-usage of already created bitmaps for a new
RenderTaget, but this leads to needing a LO-livetime
RenderTarget to create all the Bitmaps for.
So I implemented that and it works and is fast.
Added buffering for GeometryData, ID2D1PathGeometry.
I prepared this already using the
CreateTransformedGeometry functionality of Direct2D,
so the B2DPolygon/B2DPolyPolygon can get buffered
in an unchanged form, re-used as source for
creating a ID2D1PathGeometry by calling
CreateTransformedGeometry. This could also be done by
manipulating the current transformation, but is not
necessary.
Simplified buffering by directly using derivated
helper classes (from basegfx::SystemDependentData)
as data holders, thus they can reliably call
Release() at incarnated Direct2D instances without
the need to keep record of this outside.
Completely removed OutputDevice from the
D2DPixelProcessor2D, it was anyways only used in
the constructor.
Removed the need to hand over the pixel size of the
pixel target when constructing a D2DPixelProcessor2D,
instead get that values from HDC directly. Also made
D2DPixelProcessor2D exported from drawinglayer for
further experiments.
Checked if I can use higher-level Direct2D versions
by using MS's QueryInterface to see if involved
classes are higher-level ones. This worked and
allows to paint the alpha channel for
TransparencePrimitive2D now indeed using the
BlendMode that is missing in the initial D2D stuff,
so activated that (much faster).
Aded the environment variable (for Windows only)
TEST_SYSTEM_PRIMITIVE_RENDERER to allow easy tesing
of SystemPrimitiveRenderer. Since Skia enabled
does collide in quite some places (see above) I
added hat this also disables Skia in it's central
isVCLSkiaEnabled() method. That way it is easy to
compare/quickly change between versions.
Removed maCurrentTransformation, this is just not
needed for a pixel-only renderer, see comment in
VclProcessor2D's header regarding that.
Added snap-to-pixel functionality.
Added direct support for PolygonStrokePrimitive2D,
so all lines which
- are fat or thin
- have LineCap
- have LineJoin
- use dash
can be directly rendered by Direct2D. This is especially
good for dash since no decompositions will be created
for these cases.
There is an exception for our own rarely used style
B2DLineJoin::NONE, that still needs to be decomposed,
but could also be added to the impl if needed.
There were also quite some 'conditions' for supporting
B2DLineJoin::Miter in Direct2D, but I managed to solve
them all, so Miter is fully done in Direct2D in this
example.
I also added example debug code to demonstrate how
it is possible to simply add decompose paint and the
system-specific implementation to optically compare
and play around in a running office to identify
possible problems/differences.
Improved handling of TransparencePrimitive2D massively
to a more future-proof and more common methodology by
using the Direct2D mechanism ID2D1Effect and the
CLSID_D2D1LuminanceToAlpha effect. For details, see
comment in comitted code at implCreateAlpha_Direct.
As explained in refs/changes/87/141087/22 I did add
now a tooling derivate of D2DPixelProcessor2D that can
be used to render sub-content without having to deal
with patching the current internal state of the running
instance, called D2DBitmapPixelProcessor2D. It resides
in the cxx file (so being safe from other usages), has
and creates an own ID2D1BitmapRenderTarget to work on
and will come in handy for other occasions that need
to prepare a in-between result.
Made stuff in the renderer itself more private and
added access methods to protected section, use
those in tooling.
Change-Id: Ie5803f9afa3f62dbaa8fd2f1bac8fd30a23066b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141087
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Currently /Alt texts are generated from ObjectInfoPrimitive2D, but this
is only evaluated in VclMetafileProcessor2D::processGraphicPrimitive2D()
so while it's created for every SdrObject, it's ignored in most cases.
There doesn't appear to be a reason why this is done in
processGraphicPrimitive2D() and not a more generic location, the special
conditions that are checked there don't have anything to do with Alt
texts, they effectively guard some optimisation done to bitmaps in
PageSyncData::PlaySyncPageAct().
There is another issue in that not every SdrObject gets a
StructureTagPrimitive2D, and even if there is a StructureTagPrimitive2D
it may be ignored if it's in the background.
The Alt text must only be produced if there is a structure element for
the same SdrObject, else it would end up on some unrelated structure
element.
Fix all this by moving processing to a new function which checks that
there is a current StructureTagPrimitive2D for a SdrObject in effect.
The only problem with this is that previously Writer images produced Alt
text, and now they don't - but Writer needs some fixing anyway.
Change-Id: I2a362e8a9cd93e5bc817c6eed546c46b46e14980
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143189
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
... frame in the structure tree.
The problem is that in sw, the anchored objects are painted
outside of the call to paint the page frame, which is what generates the
/Document structure element.
For Writer fly frames, this is handled via their SwFlyDrawObj painting,
where SwTaggedPDFHelper::CheckReopenTag() finds the anchor frame and
temporarily sets it as the structure parent, even if it's on a previous
page.
But all the SdrObjects on a page are painted by 2 calls to PaintLayer()
and there isn't a call back into Writer now.
Somehow this even causes a spurious line like "/Document<</MCID 7>>BDC"
to be emitted outside any PDF object, which looks clearly wrong.
Try to extend the SdrObjUserCall to get a way to retrieve the anchor
frame's structure element index.
Another option would be to extend ViewObjectContactRedirector to return
the PDF Id in its subclass SwViewObjectContactRedirector, and it seems
possible since its only one caller is
ViewObjectContact::getPrimitive2DSequence(), but Armin adivses that the
ViewObjectContactRedirector might go away in the future so it's better
to use SdrObjUserCall.
It's annoying that the mapping is a static members of
SwEnhancedPDFExportHelper; possibly it could be in OutputDevice's
PDFExtOutDevData instead?
Change-Id: Id61faae469aba4f0bd278ab2324aae06c1fdde64
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143027
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
This primitive is created if a text edit is active
and contains it's current content, not from model
data itself.
Pixel renderers need to suppress that content, it
gets displayed by the active TextEdit in the EditView.
Suppression is done by decomposing to nothing by
default.
MetaFile renderers have to show it, so that the
edited text is part of the MetaFile, e.g. needed
for presentation previews and exports.
So take action here and process it's content.
Note: Former error was #i97628#
Change-Id: I32c83c0ad7883a79fc40f5a21ac6ed7b1055b7df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142910
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Currently SvtOptionsDrawinglayer::IsAntiAliasing() is used
in the constructor of the VCL based processor2Ds to decide
if AA is to be used or not. Using this inside the
constructors makes it currently impossible to use a
primitive renderer independent from these settings,
except when changing these settings temporarily what
may influence other renderings and is a hack.
The setting SvtOptionsDrawinglayer::IsAntiAliasing() is
intended to decide if LO shall use AA mode from user's
perspective, this means for the EditViews of the Apps
and some other occasions (previews, exports, conversions
to bitmap, ...).
This works currently since all visualizations for these
purposes use newly constructed primitive renderers. But
there is no way to use primitive renderers independent
from that setting. For future renderers which might be
used for other purposes this is not sufficient, there
has to be a method to create a renderer using e.g. AA
independent of the global setting.
To allow that, move the deciding flag to the already
used geometry::ViewInformation2D. To not change anything
initially, use the global flag for now to init that
default value at ViewInformation2D.
I took the opportunity to adapt ViewInformation2D to
no longer being read-only and not changeable, it uses
internally an impl class based on cow_wrapper already
anyways. Extending this would lead to the constructors
getting even bigger, when usually only 1-3 values
need to be changed and many usages want to copy an
existing instance and modify it. Adapted that usages
to a much smaller footprint.
Up to this point this does not change anything, but
move the usage of the SvtOptionsDrawinglayer to the
defaults (constructors) of the involved class
ViewInformation2D. Using this then in the primitive
rederers should be safe and will allow to use a
primitive renderer with or without AntiAliasing
independent of the user setting, so also for non-
EditView usages.
Also already added the PixelSnapHairline setting, this
will also be needed independent of user settings to
have full freedom of usage.
Unfortunately I cannot use SvtOptionsDrawinglayer
methods
::IsAntiAliasing() or
::IsSnapHorVerLinesToDiscrete
inside ViewInformation2D where I would need it. It's
now in drawinglayercore and thus not linked against
svtools (svt) anymore.
Thus I have to do some forwarding mechanisms to get
the correct values available in ViewInformation2D.
Not nice, caused by creating drawinglayercore...
Change-Id: I9f572ce67e5d86a242188bdc6d4ba7c9a12f6a9b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142393
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
There was processorfromoutputdevice.cxx|hxx containing
createBaseProcessor2DFromOutputDevice that does exactly
the same thing as createProcessor2DFromOutputDevice in
processor2dtools.cxx|hxx, so I removed one onf them
to make handling of future changes easier.
Change-Id: Id8d49d1572a1bc39f1d330a742d4697c8c030e75
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142320
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
For extended discussion & background information please refer
to the comments added to the code there.
Had to handle view-dependent parts like the hairline
different, do not buffer that case. It could be, but it's not
expensive and would require to remember and check against
the view-dependent part which was used to create the
B2DRange initially.
Change-Id: I10df46207990865c667d41f56aedb8f0956a1706
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142114
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
When the Primitives for the Glow-Effects were added
(modified ShadowPrimitive2D, SoftEdgePrimitive2D and
GlowPrimitive2D) a modified version of impBufferDevice
was created and used. That lowered the speed for
drawing objects with transparence by about factor 2.5
and was unfortunately not only done for these
Primitives, but for transprent objects in general.
For the mentioned factor refer to:
Patch to demonstrate former and now repaint differences
https://gerrit.libreoffice.org/c/core/+/129301
After having reworked those Primitives to use another
mechanism and being decomposed so they will work in all
now and future renderers, it is possible to go back to
that easier and faster method to render Transparency.
For extended information, please take a look at the
added comments, mainly in vclhelperbufferdevice.hxx
Identified a still bad behaviour when objects use a
TransparenceGradient. Corrected that and added (at
this opportunity) a method 'createAlphaMask' along
with 'convertToBitmapEx' which is now used in the
GlowPrimitive2D & ShadowPrimitive2D which only need
the AlphaMask to do their job anyways (I had commented
there that thjis is possible before). That will
be faster for visualizing those Primitives.
Change-Id: Ieac880384de26960c2c4b8740a1dee1e15d7ac9e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140022
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
This is pretty much the same for ShadowPrimitive2D as the
change for GlowPrimitive2D and SoftEdgePrimitive2D, so for
more comments please refer to those commits:
c2d1458723707b0c328a
There are some needed differences due to ShadowPrimitive2D
having existed longer and is used for non-blurred shadow
for a long time and is used as unchanged as possible.
Only for active glow of shadow is a buffering and local
decompose used.
Change-Id: I55e6516f59390079356ac16f24743b474e53fb05
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139858
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
This is pretty much the same for SoftEdgePrimitive2D as the
change for GlowPrimitive2D, so for more comments please refer
to commit c2d1458723
Added suggested change of DoSaveForVisualControl mechanism
Change-Id: I28901e7a0b6e1823000d2aa6a335ce2fd80e6ce3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139585
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
...and adapted GlowPrimitive2D to it as a preparation to
use similar to BufferedDecompositionPrimitive2D, but for
primitives based on GroupPrimitive2D.
Change-Id: Ia1f9a09d4db09238ebbf6ad1303a4cdbdb8baedf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139099
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
The new version does all needed stuff inside the GlowPrimitive2D
implementation. Advantages are:
- there is no need anymore to handle directly in the renderer
implementations. That includes HitTest & future renderers, but
also the currently existing fallback from MetafileRenderer
to PixelRenderer
- the buffered B2Primitive can re-use the last, potentially
expensively cerated pixelation result
- it checks for the possibility to do so using various
aspects (see implementation, more would be possible)
- it no longer uses impBufferDevice in the not wanted
double-vdev/alpha-channel mode from presentation engine
- it offers an example how to do all this with just a
primitive (that can be replaced with another impl if
needed without having to adapt any renderers). To
support that, I added plenty of comments
The group of GlowPrimitive2D, SoftEdgePrimitive2D and
ShadowPrimitive2D use impBufferDevice in that much slower
and expensive mode (two VDevs, processor-based alpha
mixing). To get back to faster transparence rendering
in general this is a 1st step, we also will need to
re-work the other two mentioned primitives.
The reworked one is now more efficient.
Change-Id: I25c6fb970682b5311ce6f9ca4abf2702fb7c8862
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138973
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Communicate Kashida insertion positions in an explicit way.
Rest of LibreOffice communicate adjustments to character widths (e.g.
for justification or spacing) using so-called DX array. DX array is an
array of absolute character positions (e.g. DX[n] is the position after
character n from the start of the lines, and its widths is DX[n] -
DX[n-1]).
This DX array is modified also when Kashidas are inserted after a given
character for Arabic justification, by expanding its width. VCL would
use this to know where to insert the Kashidas and how many ones.
But because DX array is used for both widths adjustments and kashida
insertion, this turns out to be a source of bugs since VCL has tosecond
guess the DX array to find which is pure width adjustment and which also
involves Kashida insertion, and the heuristics it uses are fragile.
This change adds a second array of booleans that records where Kashida
is inserted and communicates it all the way from where Kashida insertion
is decoded in Writer and down to VCL layout.
This change passes the Kashida array only when it seems necessary (e.g.
during drawing but not when measuring text since the DX array is enough
in this case). Hopefully no places where Kashida insertion needs to be
passed down were missed.
A couple of glyph and layout flags that were used for old heuristics and
no longer needed and are removed.
This also fixes:
tdf#87731
tdf#106309
tdf#108604
tdf#112849
tdf#114257
tdf#127176
tdf#145647
tdf#146199
Change-Id: I4ed0850ef2fdc3e9143341afac649e7e7d463c39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138068
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
React/interpret new SlideBackgroundFill mode for SdrObjects/
XShapes, defined by drawing::FillStyle_NONE and usage of
XFillUseSlideBackgroundItem as (true).
Do so by adding a detection, a mode to SdrFillAttribute,
reacting on it by creating a new implemented B2DPrimitive:
SlideBackgroundFillPrimitive2D provides a Primitive2D for
the SlideBackgroundFill mode. It is capable of expressing
that state of fill and it's decomposition implements all
needed preparation/creation/collecting of the geometry
in an isolated and controllable space and way - the
B2DPrimitive way. It does so based on the given
ViewInformation2D, reacing out for all needed data/
geometry from this.
It clips & transforms/combines as needed, providing the
necessary visualization of the MasterPage content *over*
other objects on the Page/Slide. It is currently simple
buffered (due to being derived from
BufferedDecompositionPrimitive2D) and detects if
MasterPage changes. Still, more may be needed.
Change-Id: Ie11403c0b705fc2ecdfd7eb2fa5ae1a93a21b460
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135971
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
(*) we can move the data rather than copying
(*) it should definitely not be const
(*) we can use STL functions to do most of the work
Change-Id: I02b4cbbdeed0588d592f24942d31608f2119561c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135083
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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>
This separates the drawinglayer core functionallity into a
separate library, to keep a strict separation what is backend
dependent and what is not. More strict separation can be done
at a later date.
This will make it possible to push part of drawinglayer
(part of processor2d) directly into VCL.
Change-Id: Ibc26580067e50bf20d7cdd37fa0e44eb10200878
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127286
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Andrea Gelmini