Age | Commit message (Collapse) | Author |
|
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
|
|
Change-Id: Ie35705bf4559f977c7a7b67edb6b05b6cd564249
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174062
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
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>
|
|
Change-Id: I459945f142055186fc103a2e0e7b3f347e02c680
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173822
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
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>
|
|
Change-Id: Ia25fe2f3c5ff4904530ea8c296d10bbbe2823af5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172394
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
now that find-unused-includes was expanded with detecting these
Change-Id: I9f21ad1a85c1e3178cad98464b2ba407d909b62d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167638
Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
Tested-by: Jenkins
|