Re-Enable DrawTransformBitmapExDirect for render backends

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>

1 files changed, 1 insertions, 1 deletions

diff --git a/canvas/source/vcl/canvashelper.cxx b/canvas/source/vcl/canvashelper.cxx
index 918a8f5f97fe..2ba45cbfa75d 100644
--- a/canvas/source/vcl/canvashelper.cxx
+++ b/canvas/source/vcl/canvashelper.cxx
@@ -721,7 +721,7 @@ namespace vclcanvas
                 // itself serves this purpose
                 return uno::Reference< rendering::XCachedPrimitive >(nullptr);
             }
-            else if( mpOutDevProvider->getOutDev().HasFastDrawTransformedBitmap())
+            else if( mpOutDevProvider->getOutDev().ImplementsFastDrawTransformedBitmap())
             {
                 ::basegfx::B2DHomMatrix aSizeTransform;
                 aSizeTransform.scale( aBmpEx.GetSizePixel().Width(), aBmpEx.GetSizePixel().Height() );