| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The task shows that for some situations the Controls do not
get vbisualized. These *should* be child windows of the
panel containing them, but fir some reason these seem to
get incarnated by being 'painted'.
Problem is that for SDPRs an OutputDevice to do so is not
available - by purpose. Luckily it is possible to use a
awt::XGraphics and 'paint' from there.
It would also be possible to find out why the child windows
do not get constructed and where this may need to be done,
but for now just add 'painting' the Controls by using the
path utilizing the awt::XGraphics mechanism. For that
purpose, do set an awt::XGraphics at the CairoSDPR if it
gets constructed using an OutputDevice.
It may be that we need to think about how to solve this
for SDPRs that get constructed from scratch, e.g.
when using createPixelProcessor2DFromScratch. This would
mean to somehow construct a awt::XGraphics from a cairo
surface, probably using an OutputDevice as in-betwen
step, but for now this change solves the problem.
Change-Id: I3bc653deab7f0b2902081b0fdbd501dfcc78383b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180967
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
"paintPolyPoylgonRGBA"->"paintPolyPolygonRGBA"
Change-Id: I9969634d9bd286c25b8c1953b1b7ddf1a4bf4629
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180654
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Thus Cairo is offering a full-fledged double precision API but
internally uses a 24.8 fixed-float format (see https://gitlab.
freedesktop.org/cairo/cairo/-/issues/252, thanks Caolan for
finding that). This seems to be the case for linux and windows
implementations. Due to the API being on double precision this
is an implementation detail, but it has to be taken into
account when using cairo. It is not officially documented what
is a shame - it should be somewhere in the readmes/
documentation at a prominent place.
24.8 means coordinates are limited to +/- 2^23 (usually minus
one) and [0/256 .. 255/256] places after comma. This is
unfortunately not limited to the view coordinates - that
would be acceptable, discrete/pixel areas of that size should
be fine, BUT used with transformations. Thus when having any
coordinates beyond that limit - and with double precision and
transformations we have that here - cairo just 'cuts' the
coordinates to it's min/max 24.8 format. This is not acceptable
for e.g. a cad system, and even leads to problems in something
like an office suite as we see. It implies that using cairo in
a safe way means to basically use linear algebra yourself in
your app and use cairo only without transformations and with
discrete view coordinates (pixels). AND to know about that
limitation in the 1st place ...
Well, cairo works well and that problem happens until now
in one place in writer below page 490. Let's be pragmatic.
Key is to *detect* the situation. Always doing own
transformations is possible, but not nice: I *could* always
transform the polygon to screen coordinates, but that will
kill the PolyPolygon buffering mechanism (in chart we have
PolyPolygons with 80.000 entries :-); These are held in
cairo_path_t form at the original PolyPolygon to not need
to transform them every time, but let Cairo do that. The
idea is that when Cairo impl may use HW on the system to
do that (HW can do that nowadays) while rendering the
PolyPolygon from the object model would have to be
converted just once to Cairo form and used multiple times...
Cairo *should* be fair, document this and allow you to test/
ask if this limit exists in the version you are using, but
it does not. Thus I suppose to detect that situation as
'cheap' as possible and react to it - e.g. in writer when
below page 490. But not only - it might be possibe to
construct draw/impress pages (free definable) that also reach
that limit.
With detecting as cheap as possible I mean: Naturally you
would start to test your geometry to be painted if it is
overlapping or outside that range defined by 24.8, but
that would already involve transforming all geometry by
world and view transformations. I think it should be okay
to just take the target area (starting at 0,0 and having a
size in pixels) and transforming that back to logical world
coordinates. Then this needs to be checked only if view
transformation changes, not object transformation. Usually
view transformation is setup and all/many objects are
painted to it using object transformations. Detection
should then only be needed when view transform changes.
Thus I added a test (see
checkCoordinateLimitWorkaroundNeededForUsedCairo()). This
is esecuted once per office runtime. If it detects that
the problem is there it sets a flag. Depending on this
the view coordinates are then transformed to logic
coordinates and checked if these are completely inside
the coordinate area that ciaro *can* correctly handle.
This has to be done once per CariroSDPR since (currently)
ViewTransformation is not changed (has to be adapted if
this should happen one day). Based on that the single
helpers on the renderer have to be adapted: Simplest
is just to render using ViewCoordinates - and do
transform object geometry using basegfx/our own stuff
that does that correctly (with ease :-).
Done that, checked, works AFAICT. What a bad surprise,
but I can work around it...
Change-Id: Ic33d6ccfe9854af396d0ac9f14c76eb25bb9e4e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180529
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
|
|
Moves the StructElement out of PDFWriter and changes it to enum
class. This makes it mroe type safe, easier to search and more
clear what type we are using.
Change-Id: Icf469319a01f58397b131c3517bc75fba4072500
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/179977
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
test drive the new bin/find-unneeded-includes --fwdecl mode
Change-Id: I507fa2b172ec9e348d1d91066ea241f02187b5ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/179321
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
We need to render each animated paragraph of a SdrTextObj in its
own layer. This is not easy to do, so modify the PrimitiveContainer
after rendering and turn off all the paragraphs that shouldn't be
rendered. In addition also turn off rendering of the object itself
(the fill and stroke). This can be done by setting the newly added
setVisible method on the desired TextHierarchyParagraphPrimitive2D
to false (and others to true), and turning the primitives to render
the object to setVisible = false. If the primitive is not "visible"
it will be skipped in the when rendering with VclPixelProcessor2D.
Also changes the SlideshowLayerRenderer to take into account the
rendering of paragraphs. We remember all the paragraphs for an text
object that are animated, then we take this into account when we
do render passes.
We also need to take care of the paragraph hash, which needs to be
set consistently for all animated paragraphs (so the layers can be
identified correctly for animated paragraphs).
Change-Id: Ice3b9e1f586c3fca81cf5da809fa88c4b9c87c37
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/179599
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Controls need not to be rendered when they are
visible as Windows (they then render themselves).
Also added some needed cleanups for better display
of control primitive decomposition as Bitmap.
Change-Id: I976cd791f9f080a7ab567232303d5d4f0b6dff05
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178725
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: Ie010deb5cdf9da20f2ca60d79feabf1c0de93c57
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177669
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
after
commit 664ecbd8916478cdc28a9c793fbdb9359b3cac64
Author: Noel Grandin <noelgrandin@gmail.com>
Date: Wed Nov 20 16:08:14 2024 +0200
remove OutDevSupportType::TransparentRect
Change-Id: I57804ec9e9967c7082a1f657165d967d75b1dedf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176910
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
Change-Id: Ib14a2e6b41165887fcf99c3d155850faa8564822
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176218
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which allows us to eliminate a bunch of rounding at various layers, and
consequently maintain a lot more precision
Change-Id: I911dedd7c041c1d67396c082e5695346ea689acb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175814
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I39388963a7e9b37c91e6b39e0af68a21de114431
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174344
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I2758c5ebacea4917beb3bedd96fa01f8e4ad2917
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174346
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
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>
|
|
Use static_cast instead of dynamic_cast when it makes more sense
to do so and use auto to make the code more readable (when we
write the type 2 times).
Change-Id: I433885ab11437b1e086e0b8e255ed9dbe7e43b90
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173978
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
|
|
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: I7ce859d402626da156ff36247d987a3fe3010e47
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172837
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I14d477dbeb9a18cc6f9d750b5d1f837117c22eaf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172798
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
- Add new text Glow effect properties for shapes
- Using TextGlowPrimitive for rendering uniform text glow in shapes
- Add/allow new UI Glow Effect for texts in shapes on sidebar
(Only for Impress/Draw and Calc)
- Import/Export ooxml files with Glow effect on texts in shapes
(Only PPTX/XLSX)
- Import/Export odf files with Glow effect on texts in shapes
- Add unit test for glow text attributes in ODF
- Add uni tests for OOXML import/export
Note: Also this patch effects on
tdf#144061 - Effects: Allow GLOW to apply to Text (as we have for shapes)
Change-Id: I16586c01654f197f532129e4e06aa2ef9f214395
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172216
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
Change-Id: If739dd9f28f56874978c7b3a76e1234e5f430c9f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172319
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: I7fb1c885e46a23e999ea4c98a73d3d526a2923e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172245
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: Idcb33e0f799b2219a4e737d0421bc21d85b5c7aa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171915
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
|
|
and
cid#1616499 COPY_INSTEAD_OF_MOVE
Change-Id: I21b089cab036902a7ba5b725a6eae0f1212f2b31
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171923
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I8c8820066a402653bf0f49bd78a98be692530e42
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171892
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>
|
|
Change-Id: I923069582bb7c5022cfbff7e869c1d577a9123ce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171691
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
|
|
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>
|
|
The EditEngine decomposes it's content mainly to
Prmitives (there is still a direct paint mode used
in rare remaining cases which we not yet got rid
of). For TABs the special case for 'extended' TABs
(see format/paragraph/Tabs, FillCharacter) was
handed through all layers using method DrawingTab,
put into a DrawPortionInfo and held at the text
primitive (TextSimplePortionPrimitive2D). While
for direct paint the expansion was already done in
ImpEditEngine::Paint anyways (and always painted,
independent from bStripOnly what was unneccessary
and I corrected that, too) it had to be done for
text paint in VclProcessor2D for each repaint.
This is not needed, so now the extended text
created in EditEngine decompose gets used.
This makes a lot of stuff simpler, including
EditEngine/Outliner and some involved classes.
If it somehow should show that it might be
necessary to do that for each paint it should
be done in the obvious way then - using an own
primitive that creates the expansin in the
decomposition (and buffers it).
Change-Id: Ieb02219142af8f6bee01dcd658e08b185a4212cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171380
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
FillGradientPrimitive2D/ and PolyPolygonGradientPrimitive2D
now support both alphas, a gradientAlpha and a unified one.
This allows a processor to directly handle a gradient with
a unifiedAlpha if he wants. Adapted other places accordingly.
NOTE: In VclMetafileProcessor2D handling of the primitive
PolyPolygonGradientPrimitive2D has to do a local compromize,
see comment there.
Change-Id: I536f4935dafde0369f768dbd281d547b7bb08eb4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171052
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
|
|
Change-Id: Iec45b32fce6381564f21c79d999a8db9a7757518
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170981
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I582bf693085251725b314b6caab9247650b25c6f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170980
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Up to now these needed to be decomposed to be
rendered and did not support animation. I already
added animation, but that was a compromize.
Done that now in the correct way, so that animation
is possible and can be directly rendered using
a FillGraphicPrimitive2D if wanted, including one
extra layer of alpha, too.
This will also enhance other primitive processors,
but of course most those that do handle that now
directly, so CairoPixelProcessor2D does that.
Note that it does not need to support animation
in any way (that is part of the primitive stack),
but just direct tiled rendering.
Change-Id: I8860098dfb3f2369e361579cf1deea7c67b662b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170937
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>
|
|
Change-Id: Icfce04f91f76119f970073bbcdbe65770f0e31c3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170798
Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
Tested-by: Jenkins
|
|
Change-Id: Id1480297126bcc422945df7cd47993cc7fe5c22a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170768
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
|
|
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>
|
|
Change-Id: I702043c566f79a81c6b40b7062cd1a83dcdaf652
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170575
Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
Tested-by: Jenkins
|
|
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
|
|
Improve the hit-test machinery so we don't need to rerender the graphic
when moving the mouse over it
Change-Id: Ide088296aa9c2be1348b8908194f47378454ae40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170587
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
Detect where created when a RGBA gradient could be
used directly and create a primitive representing
that, a PolyPolygonRGBAGradientPrimitive2D.
That primitive decomposes to what was created before,
so no primitive renderer has to be touched, all will
work as before.
NOTE: That helper primitive just holds references to
what would be created anyways, so one depth step
added but not really any additional data.
This is the 1st step for direct support, the 2nd is
to then detect and use that primitive in SDPR
implementations directly.
Change-Id: I4f247636ce58a8a1fd1e0df32dabed0d6cc10d0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170527
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Avoid decomposition of it in AnimatedExtractingProcessor2D
by handling there directly. Goal is to find/extract animation
primitives, so only do something when the contained Graphic
is active
Change-Id: I1d168428ddbaaac2c9d5fde7b26be380ba442c30
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170203
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: I0e722e9438e7e21d4fa8ba05a9bd56719db521fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170144
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>
|
|
This is the way it's done everywhere.
Partially revert 4b6e0f2c88debaedb514c868e061c21e15215b6e
"tdf#160726, tdf#48062: Simplify how BitmapExs are created"
Change-Id: I15fea0b6855a65da7cb48b24fc00ba303e33dcf8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166456
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
In my initial approach, I tranformed the primitive2DContainers
before converting them to BitmapEx. This caused circles like
https://bugs.documentfoundation.org/attachment.cgi?id=193790
not to be displayed.
Simplify how BitmapExs are created by just using the range both
primitive2DContainers have in common. This way, DrawBitmapInRect
can be dropped now
Change-Id: I2401dc87b98e04b9cf9f5ebade2b5622d884fc3a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166391
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Opening an SVG with text in different elements (e.g., tspans) in the
same text element performs calculations to position the parts properly
(i.e., the next part will start where the previous part ended, unless
the position in overridden explicitly). These calculations require to
know the text widths. The first problem leas here: the text width was
calculated for a typically small text size (numerically equal to the
pixel size defined in the SVG), but these calculations aren't truly
linear, because font rendering may change depending on font height.
Additionally, the rounding gives much higher error in smaller sizes
than in larger. There was already a workaround for a similar problem
in ViewRedirector::createRedirectedPrimitive2DSequence, where a large
font (with 100 times greater height) was used to increase correctness.
This was also used here, with the same large height (50000) used as a
reference.
Then, at the time of wrawing the text at different zoom levels, the
code in VclProcessor2D::RenderTextSimpleOrDecoratedPortionPrimitive2D
creates a font of a calculated size, and uses it to output the text.
But the font is always created with an integral height, which means,
that for a wanted height of 2.5 (in a zoomed out view), the really
used height will be 3, which is 20% larger; or for wanted height of
2.4, the actual height will be 2 (20% smaller). This resulted in odd
jumps of the text widths, when the text may overlap the following
part, or conversely, create a big gap before the next gap. To try to
mitigate that, the function now takes the difference between the
wanted and the actual font size into account, and adjusts the MapMode
accordingly. This doesn't fix the jumping completely (e.g., because
of the mentioned special handling of small font sizes in the fonts
thenselves, like hinting), but still makes the calculations much more
stable, decreasing the amount of jumping. Similar changes are made in
TextLayouterDevice.
Use of the functions that return text size as a double, not rounded
value, should additionally help improving stability.
Change-Id: I455845d8ca43ee9c06a0fc980947f35d8a25797a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166238
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
create a plugin that finds methods we can mark as final because they are
not override in subclasses.
Which is useful both as documentation (telling you that you don't need
to worry about subclasses changing the implementation under you),
and for performance, letting the compiler elide virtual calls in many
cases.
Apply the results to a subset of stuff in /include
Change-Id: I7b5cc893ec2f343bc356bfc338e4cf531ffba1e0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165054
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
