| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: Icab045ac04f3e556672191b8df454f8f29ecc6d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134221
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I454c945c5ce17bcc1834923064014b43a0b45be7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131186
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
The parameter to PrintFontManager::countFontconfigFonts() was only
written to since babf6d5e53516e80e8e3f2485796ebfaeb20e9c1.
Change-Id: Ie206fdbd620f1cfc6402c1d02709c3b653140c85
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131097
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
It passed "make check"
Change-Id: I0828ea2c2531cb970f32581333776f02a46a8d5e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129314
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
This reverts commit 7e5af164b7d293dd410710bed411e1ca64bbecf7.
Reason for revert: Not the best/effective way to clear out the stuff remaining to be done, would need additional stuff
Change-Id: Ia6ab90384da29a5e34eff0ab8881bad2ab49c58c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126601
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Unfortunately the add/usage of HasFastDrawTransformedBitmap did disable the
system-dependent implementations/fast-path for DrawTransformBitmapExDirect
and it's implemenations, except for Skia.
This means that the current backends for Windows/Mac/Cairo/headless/Qt5
have to do expensive pixel operations when a Bitmap is 'really' transformed
(rotate/shear) since some time.
The nine implementations using ::hasFastDrawTransformedBitmap (grep for it)
all return false, except the Skia one.
Since HasFastDrawTransformedBitmap() uses that and itself is used in the very
central mehod OutputDevice::DrawTransformedBitmapEx(...) to decide if that
fast-path shall/can be used at all, it was *no longer used* - except for
Skia - what makes Skia definitely performing better with transformed Bitmaps,
or the other way around - the others worse.
HasFastDrawTransformedBitmap() is used in only two places, the second is in the
canvas helper to decide if to try to use that fast-path for presentation
rendering.
A method at OutputDevice to see if that fast-path is implemented is therefore
currently needed, but for the canvas helper only. Since this will/should be
converted to primitive usage (hopefully) anyways, nine impementations calling
these virtual functions often and the danger to produce a mismatch/
error beween implementations of hasFastDrawTransformedBitmap and
drawTransformedBitmap (as happened here, but can also happen when someone
adds or removes an implementation) I looked for a way to solve that differenly
and more safe.
Since SalGraphics::DrawTransformedBitmap anyways returns a bool to signal it's
success I take this as base to implement a buffered test directly at
SalGraphics, also directly set a local flag to detect that functionality if
DrawTransformedBitmap is used anyways before the test is/would be needed.
Combined wih that small test to check only if this was not yet used and thus
tested by DrawTransformedBitmap anyways I can offer a reliable non-virtual
method at OutputDevice called ImplementsFastDrawTransformedBitmap() that will
be used at the single necessary location - in the canvas helper.
Since that small test direcly uses one of the nine implementations of
hasFastDrawTransformedBitmap it is fundamenally more reliable and probably
the copy bitmap/writeBack never really used (I tested that it works) due
to an earlier use of DrawTransformedBitmap did the check potentially already.
I also took a look at the cairo version (since I had this one running here)
and ensured that the buffering of the system-dependent form of the Bitmap
as cairo surface still works. Regarding the newly introduced fAlpha
parameter I want to add some remarks:
- It should be called fOpacity to make clear that it describes opacity,
defining that if 1.0 == fAlpha means *no* transparency. That word is
used in other graphic systems and makes more clear what function it has.
It is the opposite of transparency, but works the same.
- Currently all implementations of ::drawTransformedBitmap - except Skia
where it was implemented - do not use it, but return false. It will in most
cases not be too complicated to add/implement it, e.g. for cairo anyways a
transparency surface will/is created, fAlpha can just be merged in, and the
criteria for buffering that may be extended to remember for which value
(if at all) of fAlpha that was prepared. I strongly recommend implementing
these for our main graphic backends.
- The primitive renderer uses another more general way to add an extra alpha
channel to paint when needed - it draws the content (any content) that needs
to be transparent to a buffer and then that buffer using the intended
transparency. This is discussable since may be more expensive, but more
general and keeps the interface less complex. We can see here that adding
that complexity to the existing interface at OutputDevice makes the
implementations more complex what might be the reason his was only
implemented for one of nine backends. When adding something like this and
extending the complexity I would prefer that at the same time it gets
also *implemented* in all or most or at least most used cases. I want to
make clear that from my POV in those cases choosing possible runtime speed
over complexity is not always preferable.
Change-Id: I5bab59f59fca878a7b11a20094e49e8b50196063
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126480
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
And apply some of the results
Change-Id: If555476fdd951cbc1d01fb3ef3ab1cbca2b64960
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124896
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
update the script to use python3, and run it
Change-Id: I9c2a86e1f7a2eb889dcf214f2a2f6a31ceb1f59e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109710
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I224831ad18e754fd67d9b16510cd286a5397f1f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98236
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I3115dda50e77dc6a335e46026724641c08c04030
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89949
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ief2538fb61f4519e733ce7592cc7c441b94ac124
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88030
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Mark some stuff SAL_DLLPUBLIC_RTTI in
include/vcl/metaact.hxx
in order to make ASAN happy.
Change-Id: I97febe0968bf58b9cbe60ce647f0ada25e6f4bb0
Reviewed-on: https://gerrit.libreoffice.org/84202
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
