Age | Commit message (Collapse) | Author |
|
do it like this to avoid adding another mapmode and to keep things
"the same" as much as possible
Change-Id: I1965aa545646f2d27b950d6335b2f608c3e4e04b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143475
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Turned out to be unnecessary but why not add it.
Change-Id: I8dac0f0d6ec47f98d540eb4f8c42830cd652f344
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143536
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
There isn't really an indication of anything being a header row, but the
table template application has a flag to apply special formatting to the
first row, so let's use that as indication that it's a header row
Change-Id: Ic361c84d9a1a4e91109d6f9d2cd626c9633b311f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143500
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: I52f24e50455c0d480f8976ee63e442008c05c192
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143520
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
If the range which defines the bitmap fill is defined and different from
the range of the defining geometry (e.g. used for FillStyle
UseSlideBackground) this cannot be expressed in a SvtGraphicFill data
package. Thus, just use decomposition here directly. See also
tdf#149754 in drawinglayer/source/processor2d/vclpixelprocessor2d.cxx
and the comment there for more info.
Change-Id: I8e1b26fb2bf523e6fd7af1040166f8197747e7ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143503
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>
|
|
this is one of the secondary analyses this plugin performs
Change-Id: Iaa4424c2396470c6f1df85b0290fbffdda35fa08
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143177
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
... 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>
|
|
PAC3 complains: "Figure" element on a single page without bounding box
Also add Placement while at it.
Change-Id: I3db11f5b38c46bc274e496c7ce6f0cde9dd11b01
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142902
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>
|
|
we no longer need to wrap it in the framework XBitmap
implemenation
Change-Id: I0dc56ad63364e2c5a4cedd5e70d4ae7ea7eae563
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142746
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ica799419ed628f94f134433ca5b37518c5698909
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142730
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: Ic1fb0ea483954f2994a87e05f33b320da3795227
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142661
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
As long as not all our mechanisms are changed to RGBA
completely, mixing OutDev with Alpha (2x VDev) and RGB
target rendering is just too dangerous and expensive
and may to wrong or deliver bad quality results (see
comments in code for details).
Nonetheless we need a RGBA result for convert to
BitmapEx. Luckily we are able to create a copmplete
and valid AlphaChannel using 'createAlphaMask'.
Based n that we know the content (RGB result from
renderer), alpha (result from createAlphaMask) and
the start condition (content rendered usually
against COL_WHITE). Tht makes it possible to
calculate back the content, quasi 'remove' that
initial blending against COL_WHITE.
That is what the helper Bitmap::RemoveBlendedStartColor
does. Luckily we only need it for convert To BitmapEx,
not in any other rendering.
This gives good results, it is in principle comparable
with the results using pre-multiplied alpha tooling,
also slightly reducing the range of color values where
high alpha vlaues are used, but in areas that are
highly transparent anyways.
Also important is that this will work with RGB-based
system-dependent renderers, too. The method before
could only work with the VCL-based primitive renderers
by principle (only there - by coincidence - OutputDevice
with Alpha worked).
NOTE: Had to re-add usage of *unused* alpha channel
in convertToBitmapEx due to test SdPNGExportTest. It
somehow creates an Alpha in Bitmap size when I *remove*
Alpha in convertToBitmapEx, so I just keep it for now,
it is created anyways, just wanted to make it sleeker.
Change-Id: I12e47327f5793d6ed87e217a2355c608f528246f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142547
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: I2ccc6cbee28da9f91698b470449fb76b7729f634
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142475
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.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>
|
|
Change-Id: I097aec3699f668c60a7cb18e2ad412a45ce43ad3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142182
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
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>
|
|
speeds up rendering by 5% or so
Change-Id: I9feaae75cf2779adf06fcc2429be35ac88193ccf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141893
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
* Specification: ISO 14289-1:2014, Clause: 7.18.5, Test number: 2
Links shall contain an alternate description via their Contents key as described in ISO 32000-1:2008, 14.9.3.
These links are created all over the code, in some cases it's a bit
dubious what the content/alt-text should be, but let's try to use the
most suitable looking bit of text in whatever the context is.
* Specification: ISO 14289-1:2014, Clause: 7.18.3, Test number: 1
Every page on which there is an annotation shall contain in its page dictionary the key Tabs, and its value shall be S.
Change-Id: I7b63feb759f0c75047f854ed9997918f829a537e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141826
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: Ibcfb4b102a58cad53c1ce5f569721e4557844b4d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141673
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
...which was missing in ::create2DDecomposition.
Change-Id: I585aa884e4d19bf6f34783d254f502a4c3dd6733
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141470
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I249866d1aef29d256439c0437835a173d8a4c633
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141286
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Presentation still uses Metafiles as transfer for
Graphic content, so uses VclMetafileProcessor2D.
Unfortunately processPolyPolygonGraphicPrimitive2D
does not support an active BColorModifierStack,
so use the default as working fallback to create
correct GraphicData for the Metafile.
Change-Id: Ia439b241cb414667263ef653b507ad8b7fecde61
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140550
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
...for better gradient visualization, see task
for details.
Change-Id: Idccd569b0e95763f6dbf6ad0a2204b62460c66d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140354
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: I46f3ada5c155250b56ae3c8227587b741a8144dd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140349
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
We have to use regular primitive decomposition
when the gradient is transformed in any other
way then just tanslate & scale. For more background,
refer to the bugzilla task.
Corrected some typos.
Change-Id: Ic767c9fe6d14444915facc1247ba4ec1f79fd02e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140237
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: If33ae9acbc1ed17398584efa3574566b2d854b3e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140149
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
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>
|
|
The emphasis is not quite right. An animation is made up a sequence of
*frames*, not bitmaps. A frame includes such things as position, size,
timeout till the next frame *as well as* a bitmap.
Note: had to regenerate a bunch of precompiled headers
Change-Id: Ib1959452653857555f41e01ac0151d08c41a3b1c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/76460
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Ia6b1151d6a95cf797f8e13998e2ed372aaddb18f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139914
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.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:
c2d1458723c66c2fd717a112f89f773226adc841
707b0c328a282d993fa33b618083d20b6c521de6
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>
|
|
Change-Id: Id8b3c2bcf0bf4be5aba2812b0edda479bc20c6a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139683
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
it is module private
Change-Id: Ic9e648202f23e4a48e5485237c9956501e9c96da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139736
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This is pretty much the same for SoftEdgePrimitive2D as the
change for GlowPrimitive2D, so for more comments please refer
to commit c2d1458723c66c2fd717a112f89f773226adc841
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>
|
|
Change-Id: I4f4133ca077d69e3238aba809cd758455918bc39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139586
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Stumbled about this error when working on re-designing the blend
primitives for shapes. Using convertToBitmapEx is the base for
these (also for the UNO API conversion from Primitives to
BitmapEx).
Use a VirtualDevice in the Alpha-mode now to solve it. This
creates the needed alpha channel 'in parallel'. It is not cheaper
though since the VDev in that mode internally uses two VDevs,
so ressoure-wise it's more expensive, speed-wise pretty much the
same (the former two-path rendering created content & alpha
separately in two runs).
The former method always created the correct Alpha, but when
transparent geometry is involved, the created content was
blended against white (COL_WHITE) due to the starting conditions
of the content creation.
There are more ways than using a VirtualDevice in the Alpha-mode,
to do this correctly, but this is the most simple for now - and
I was persuaded by the following argument:
Due to hoping to be able to render to RGBA in the future anyways
there is no need to experiment trying to do the correct thing
using an expanded version of the former method.
Change-Id: I23e005f9c3723059e2b88660fede09aa83844b38
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139272
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
reduce some time spent in the 3-d rendering
Change-Id: I5d622799bc101b5b988d382a039b5a3b03818d1c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139256
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...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>
|
|
That is the algorithm that doesn't change colors, BmpScaleFlag::Fast
works the same way only because it's mapped to this algorithm
(which may not necessarily be the case forever).
Change-Id: Ibebfff668eaa1da93963f8e8601fec51cfdfca34
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139128
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Apparently an empty viewport actually means everything should be drawn.
Change-Id: I55ae453a8f264d48222ade48a2953ab7d97c7f79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139125
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Iae97a43a18a8017e739eb2bb4275da6fa275aff3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139101
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I18d696cbc5685778e23bf69ce99e044db25f9a55
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139100
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
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>
|
|
Using the environment variable allows me to use a directory
where no "access denied" happens on write access.
Change-Id: Iffdd9b8566f2d794a6741b71d736d14d4643576c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139033
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
regression from
commit 1fa731d03ba0f22cb9392a578124ea977eaab2e9
Date: Tue Aug 16 23:39:53 2022 +0100
tdf#150462 don't prescale dxarray before using DrawTextArray
do the negative scaling checks as was done originally
seen with:
bugtrackers/odg/tdf35913-4.odg
bugtrackers/svg/kde82509-1.svg
bugtrackers/svg/fdo45001-3.svg
Change-Id: I9eba78218d4676d60375fb9e9403be4e9bd5182a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138871
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Always render glyphs with a mode suitable for rendering of
resolution-independent layout positions if we scale the text positions.
The idea being to typically continue to use the system defaults for font
settings for UI elements, but where we are rendering into application
canvases where there's a mapmode set then automatically use a good mode
to render that.
Change-Id: I0e5857e377da72ae1a2ede1d88d6408819fc9200
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138324
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
triggered by the recent flatten, but there since:
commit 36f21914b31a28f75ec2195c266424a18408f747
Date: Tue Oct 29 17:40:43 2013 +0000
Resolves: i123564 corrected some aspects when working with bitmaps...
with low color depth or small size
Change-Id: I5f088c3f7096cc6f2efcd370943128d6667b2d0f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138762
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
splitting part of it out into a helper function
Change-Id: I135ba5c6c823eec9f708b4652900e06fa06bbba7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138641
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|