Added general interfaces to be able to render directly
to an RGBA target SDPR:
- processor2d::createPixelProcessor2DFromScratch creates
a target-SDPR with given pixel size and RGB or RGBA,
owning and using a cairo surface internally
- processor2d::extractBitmapExFromBaseProcessor2D extracts
rendered content to BitmapEx, including alpha
All this is currently only implemented for Ciaro, thus
the internal impls are encapsulated by USE_HEADLESS_CODE,
but already created gererally available. The return values
have to be checked to see if an evtl. shortcut is possible.
For convertToBitmapEx this means that it can do conversions
much faster than up to now for cairo when CairoSDPR is
available, else it has to to the older slower way that
also works and is the default: Create RGB content, create
Mask, RemoveBlendedStartColor (see convertToBitmapEx
implementation). This works and has the same quality,
but needs two renderings and one bitmap operation, thus
is clearly slower.
Note that these interfaces can and will be supported for
other SDPR implementations in the future, thus will make
this converter automatically faster on systems where we
will have a SDPR in the future, too.
Also note that this is the gereral converter from
a sequence of Primitives to Bitmap data, already used in
many places, inculding UNO API, thus is expected to have
some impact on conversion efficiency - if Cairo is used,
so e.g. also headless.
Change-Id: Ia638a549a04b19622892d91651317ec6727b6cd0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174266
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
Unfortunaletly we have 'virtual' OutDevs, that means their
PixelSize is bigger as they claim and they use an internal
offset. This is used to not have to create too many Windows
inside Windows (AFAIR initial reason was that Windows has
a fix number of Windows per process that can be incarnated).
The offset was/is already supported by SDPRs using
ViewInformation2D and adding ot to the ViewTransformation,
but the evtl. existing PixelSize has to be clipped against.
The fallback VclPixelProcessor2D supports that indirectly
by doing that in the OutDev commands that get called, so
it does not need to be done by that renderer.
I have now added code to support that for the
CairoPixelProcessor2D, see code and comments. It uses an
existing method of cairo to do that elegantly inside the
system-dependent code of the SDPR.
Note that the Windows SDPR D2DPixelProcessor2D will
have the same problem that will have to be solved there,
too. Since it's currently in experimental state I made
myself a note about that.
Change-Id: I68915985102bb4a63c84299f8d022ab013633510
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173998
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
This is to check all builds/tests with activated
CairoSDPR to evtl. make needed additional changes
as preparation to activate this in the future.
adapted for testTdf139000():
Use no AA offset (0.5) for applying mask.
Adapted for testDoublePixelProcessing:
The trick (hack) to create a PixelProcessor and then
attact a metafile to start recording to it does no
longer work/make sense since the VclPixelProcessor2D
is no longer the only PiyelProcessor you might get.
If it is a SDPR one (e.g. CairoSDPR) it *cannot*
record metafiles - and is not intended to do so.
Since this test was already adapted 6 years ago to
the modernized decompose of a double line to just
two lines anyways it is OK to now change to use
a VclMetafileProcessor2D now initially.
Adapted for CppunitTest_svgio:
In SvgFeBlendNode::apply execute the calls for
convertToBitmapEx without AntiAliasing to get better
edges. Input data is SVGToken::FeFlood, so a
rectangular area, so no AA needed.
Taking this back: The reason must be in the renderer,
nothing else changed. Debugged in detail through
both, problem is that VclPixelProcessor2D ends up in
CairoCommon::drawPolyPolygon and draws the polygon
AntiAliased, but just the fill and thus *not* with
the AA-offset of 0.5, that is only done for fill.
I have to re-consider the AA offset decision for filled
polygons. Checked CairoCommon again, indeed AA offset
is ony done for lines, not for fill - that corresponds
with my thoghts from the weekend. Somehow this must
have come in with copy/paste (?). Same is already
in D2DPixelProcessor2D, have to remove there, too.
Adapted for CppunitTest_sd_png_export_tests:
This was a hard one, debugged all the components used
for ConvertToBitmap/MaskCreation. Cumulated to be
some diff in processTransparencePrimitive2D, but
found no error after checking all tranmsformations.
The orig errof ro the failing test (tdf#158743)
seemed to give a hint, but ObjectTransformation
was just handled well. At the end the diff was
that VclProcessor2D uses the same processor, while
CairoPixelProcessor2D creates local instances
(what is cheap). Thus the content rendering for
TransparencePrimitive2D was *not* using the set
BColorModifierStack. Added as needed to be able
to transfer that to the content rendering
instance.
Adapted for CppunitTest_sd_png_export_tests:
Gerrit says PNGExportTests.cxx:1041 asserts,
but I cannot reproduce. Maybe at the build
system a slightly different font is used.
My only idea is to add the mentioned point
at (12,120) to the rectangles, obviously the
bottom one.
Next one is (13,82), again bottom one,
adapting.
Adapted for CppunitTest_sw_ooxmlexport16:
The test 'testTdf136841' uses a WMF that contains
XOR paint parts. This showed that that part in
CairoSDPR did not work yet as needed. Adapted
that, also the test slightly due to the color
result slightly changed with CairoSDPR.
One last change before activating in master: Add
DISABLE_SYSTEM_DEPENDENT_PRIMITIVE_RENDERER in
case it urgently needs to be switched off or to
be able to simply test if something happening is
related to CairoSDPR
Change-Id: Idb8237a05d7594efe20edfa1707ca0002185645a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173330
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Handling EmphasisMarks for direct text rendering
was a hard task - the EmphasisMark stuff is deeply
buried in vcl (would have needed to move quite some
includes from vcl to public) and thus hard to use.
It is also quite old (tools Polygon, Rectangle).
It was missing in the decomposition of the
TextDecoratedPortionPrimitive2D (for good reason),
but is needed now.
I found a way using a callback lambda function to
create the needed geometry in vcl and hand back the
needed data to the caller, in this case to the
decomposition. Adding it to the decomposition of
TextDecoratedPortionPrimitive2D also guarantees
that other renderers/usages will do the correct
thing and all will look identical.
Interestingly EmphasisMarks were never added to
Metafiles (see OutputDevice::ImplDrawEmphasisMarks)
so they were not 'missing' in Metafile-based
exports. But for SDPRs they have to work. I added
another encapsulating TextHierarchyPrimitive to
encapsulate primitives that do represent
EmphasisMarks and added to ignore these in the
VclMetafileProcessor2D (as needed).
Change-Id: I5b5c1528d86a123df2beb57d8366f05aa71e77cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171826
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Cairo can render RGBA gradients directly and the
CairoSDPR supports that. If we have a PolyPolygon
filled with single color combined with a gradient
alpha the renderer could map RGB to that color
and combine with the real alpha gradient steps.
To support that I added another Primitive called
PolyPolygonAlphaGradientPrimitive2D. It decomposes
as needed (TransparencePrimitive2D if needed), so
no other renderers have to be touched.
The Cairo renderer supports it directly, though,
what makes it much faster.
Change-Id: Ie90c8bd84d6458d12443db815ced55bdea93c15c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171628
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
I have added basic support for the text primitives
(TextSimplePortionPrimitive2D) to the SDPR Cairo
renderer. It can now basically render Text using
a fallback to the already existing CairoTextRender.
NOTE: This is not yet complete, but for discussion.
Change-Id: I9b0c7b6bb4892905576593ef4e2b4071c7663c63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171429
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
To more directly support an additional alpha channel
for BitmapPrimitive data I have done some deeper
changes to the primitive stack, in a compatible
way. Quite some more graphic types and primitives
now support an additional direct alpha value. All
that is decomposed/created/broken down in a way
that needs no changes for existing renderers, in
already described ways.
The CairoPixelProcessor2D already uses this in the
processFillGraphicPrimitive2D implementation and
thus in the FillGraphicPrimitive2D. This works since
primitive productions now all try to create that
FillGraphicPrimitive2D type including an additional
alpha value - if possible and necessary.
Change-Id: Ib1b16491a2b3aee16f14cc8196e28af30a7cf9be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170900
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
This provides a BitmapPrimitive2D extended by a unified
transparency component. It will decompose to a
UnifiedTransparencePrimitive2D containing a
BitmapPrimitive2D and the transparence, so no primitive
processor has to support this primitive directly - but
can if feasible. I plan to use that ASAP
Change-Id: I83ec84eaadc8ba2b21f0ba0cb1fdcf43bdc455db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170852
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
I thought about this functionality again and decided
to change doing it in a way that will support more
alpha more directly in existing primitives - that will
be better for also supporting e.g. PolyPolys with alpha,
etc. Will need checking of existing usages of e.g.
FillGradientPrimitive2D, but it's worth it.
Note that when your primitive processor (usually a
renderer) does *not* support alpha in gradients
directly it is now requuired to continue using the
decomposition (what renderers do automatically when
calling 'BaseProcessor2D::process' in the default
case. Checked that for existing processors.
Change-Id: I840c9feb8c98549b790ef16285a309b42c4b1b53
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170687
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
This step wil now use the new primitive
PolyPolygonRGBAGradientPrimitive2D inside the
CairoSDPR/CairoPixelProcessor2D to directly
render gradients as RGBA, without painting
RGB (content) and A (alpha) separate and mixing
the results.
Note that this is only possible for gradients
which use the same graphical definition, see the
method 'sameDefinitionThanAlpha' and it's usages
in the code.
Change-Id: I6c46a211ea26d3e4b7bb39c7f2aaff09ec38dec5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170584
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
Added and corrected quite some stuff to this basic
construct provided by Caolan (thanks again!). No
detailed descriptions here, but it's getting more
complete and faster.
May contain errors and is primitive-complete in the
sense that all gets rendered, but some basic stuff
that should be directly supported is still missing,
e.g. text rendering.
Adding this to allow people to check it out (speed)
also since it's not yet used as default in master,
so it's safe and also safes the changes publically.
To test it, use TEST_SYSTEM_PRIMITIVE_RENDERER as
set EnvVar in linux systems.
Change-Id: I25f795c9ea4ad4f3b99591304f8803dffa499436
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168911
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Implements horizontal hit tolerance for quick text edit in Impress & Draw
making it more forgiving. Previously it was required to click exactly on
the glyph to get a direct text cursor.
Refactors hittestprocessor2d so that it now supports pseudo per axis hit
tolerance.
i.e. underlying isInEpsilonRange hit check is still the same utilizing
the larger tolerance of the two per axis tolerance, but the preliminary
check that uses aPolygonRange.grow() and later aPolygonRange.isInside()
now filters hit misses out with respect to the per axis hit tolerance.
Utilizes hittestprocessor2d's new per axis tolerance to introduce hit
tolerance for quick text edit, making it similar to TextEdit mode hit
tolerance which only has horizontal tolerance.
Fixes wrong use of BoundRect hit to determine text frame border hits.
Which previously only made sense for TextFrame borders, and was mostly
useless for shapes with text inside.
Change-Id: I749e63752da05b01270bfcab2632c41879a848ec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154640
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
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>
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>
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>
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>
