https://bugs.documentfoundation.org/show_bug.cgi?id=165595

Saburo <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|bibisectRequest             |bibisected, bisected
            Version|25.2.1.2 release            |25.2.0.0 alpha0+

--- Comment #12 from Saburo <[email protected]> ---
Bisection results based on response speed of character input with macros turned
off

commit  27829e4a6c5a4a1162599550c46b5e7f974aba91
author  Armin Le Grand (allotropia) <[email protected]>      
Wed Jul 10 13:16:20 2024 +0200

CairoSDPR: Improve BColorModified Bitmaps

There is the complete BColorModifierStack support for
primitives for Bitmaps, e.g. hue/saturation, etc, but
it was slow due to not being buffered, so had to be
re-created often. I changed this to use the common
buffering mechanism to improve this.
Up to now a fallback to use the old Graphic
manipulators for that purpose was in place since this
was faster, but had to be done every time. I have now
changed the priority to using the primitive way to
handle things, but kept the fallback code - just in
case.
Note that the new stuff is faster, but even much faster
when the bitmap is copied and appears multiple times ->
the same buffered instance is used, and SDPRs then use
the system-dependent data buffered at that prepared
data.
Also note that this change does not only speedup
CairoSDPR, but all PrimitiveRenderers, including the
VCL and Metafile ones. In principle everything that
uses BitmapEx::ModifyBitmapEx.
Had a 2nd thought: Only the content Bitmap gets changed,
so for this case we do not need AssociatedAlpha and
watch for it to not have changed. Removed that.

Change-Id: I2ee36cc84bdc1c723aa01f872edbfd1f51e11c2d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170305

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to