[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 BogdanB changed: What|Removed |Added Blocks||136524 CC||buzea.bog...@libreoffice.or ||g Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=136524 [Bug 136524] [META] Performance/hang/lag/high CPU issues -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 --- Comment #62 from Telesto --- (In reply to Xisco Faulí from comment #60) > Hi Leo, Tor, > Should this issue be closed as RESOLVED FIXED ? I guess so.. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 --- Comment #61 from birnb...@posteo.de --- I hate to spoil the party but shouldn't we make sure unnecessary pixel copying is safely disabled in all versions before we close the bug? The M1 framerates are phenomenal but there is a lot of Intel Macs out there. (In reply to Martin Jungowski from comment #59) > I haven't checked the source but I can confirm that the current 7.1 release > is about as fast as the Develoepr Beta that I ran my initial tests with back > in November of 2020 (see comment 52). I get around 10-12 FPS with > pre-patched versions and 25-27 FPS with the Developer Beta, 7.0.5, and 7.1.3 > downloaded from libreoffice.org as well as LibreOffice Vanilla 7.1.2 > downloaded from the Mac App Store. > > After discovering that unlike the libreoffice.org release the Mac App Store > release is already a Universal Binary I ran the same tests on my low-end > MacBook Air M1 as well, just for sh*ts and giggles. Lo and behold, my M1 Air > runs the universal binary at a buttery smooth 50+ FPS. Which is 50% faster > than the Intel binary (tried Dev and 7.1.3, both of which yielded around 35 > FPS) or any version of LibreOffice on my Intel iMac, which seems to peak at > around 25-27 FPS. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 --- Comment #60 from Xisco Faulí --- Hi Leo, Tor, Should this issue be closed as RESOLVED FIXED ? -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 --- Comment #59 from Martin Jungowski --- I haven't checked the source but I can confirm that the current 7.1 release is about as fast as the Develoepr Beta that I ran my initial tests with back in November of 2020 (see comment 52). I get around 10-12 FPS with pre-patched versions and 25-27 FPS with the Developer Beta, 7.0.5, and 7.1.3 downloaded from libreoffice.org as well as LibreOffice Vanilla 7.1.2 downloaded from the Mac App Store. After discovering that unlike the libreoffice.org release the Mac App Store release is already a Universal Binary I ran the same tests on my low-end MacBook Air M1 as well, just for sh*ts and giggles. Lo and behold, my M1 Air runs the universal binary at a buttery smooth 50+ FPS. Which is 50% faster than the Intel binary (tried Dev and 7.1.3, both of which yielded around 35 FPS) or any version of LibreOffice on my Intel iMac, which seems to peak at around 25-27 FPS. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 --- Comment #58 from birnb...@posteo.de --- Draw performance is significantly improved in 7.1.2.2, we are back in the 'usable' area. Working with more complex objects is still kind of lagging, though, and some more efficiency would be quite welcome. Could somebody please kindly check if Leo Wang's patch is part of the mentioned release? I could find no mentioning of speed related changes in the Release Notes and the bug is still open. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 birnb...@posteo.de changed: What|Removed |Added CC||birnb...@posteo.de --- Comment #57 from birnb...@posteo.de --- No notable change in 10.0.5.2. I find that slow display is even a problem even when working with text if the file is large or the user very quick. That's on a 27" Retina 5K iMac with 3 GHz 6-Core Intel Core i5 from 2019 running 10.15.7. With NC this machine is easily outperformed by my 10 years old MacBook Air 1,7 GHz Intel Core i5 from 2011 without Retina display running 10.13.4 As NC is practically not usable on a state of the art Retina Mac I propose changing bug severity from normal to major. Proposing assistance in bug documentation and testing again. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 --- Comment #56 from Telesto --- (In reply to birnb...@posteo.de from comment #55) > The bugfix does not seem to be part of 7.0.4.2 -- or it is not working. > > Could somebody please update on when we can hope for improvement on this? > Working with LO on a Retina Mac is *really* a pain. > > I have a few Macs of various ages (some Retina, some not) and gladly > volunteer for QA. So in any workflow. Not specific related to images? There pretty big issue in that area (solved with 7.0.5). Any change to test against Master? https://dev-builds.libreoffice.org/daily/master/current.html -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 --- Comment #55 from birnb...@posteo.de --- The bugfix does not seem to be part of 7.0.4.2 -- or it is not working. Could somebody please update on when we can hope for improvement on this? Working with LO on a Retina Mac is *really* a pain. I have a few Macs of various ages (some Retina, some not) and gladly volunteer for QA. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 --- Comment #54 from Telesto --- *** Bug 113104 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 Xisco Faulí changed: What|Removed |Added Whiteboard|target:7.1.0|target:7.1.0 target:7.0.4 --- Comment #53 from Xisco Faulí --- (In reply to Telesto from comment #49) > They commit has been pushed > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=87964eb39e2668f80bcbf503d9a3b55a7f86ce28 > > Somehow without notification.. probably because of the missing TDF bug > number in the commit title Backported to libreoffice-7-0 in https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-7-0=ab436ca98b11a6c72e695169662ad3b5a314fa9c -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 --- Comment #52 from Martin Jungowski --- As I have just posted in the related bug report 113104 I can report that the fix is definitely working and improved performance significantly. The sooner this is backported the better as LibreOffice is unusable on macOS at the moment. See https://bugs.documentfoundation.org/show_bug.cgi?id=113104#c31 for FPS and details. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 --- Comment #51 from Xisco Faulí --- (In reply to Telesto from comment #49) > They commit has been pushed > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=87964eb39e2668f80bcbf503d9a3b55a7f86ce28 > > Somehow without notification.. probably because of the missing TDF bug > number in the commit title Hi Telesto, Before it's backported I would like to hear from someone who could reproduce this issue to see if things have improved. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 Telesto changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=13 ||7646 -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 --- Comment #50 from Telesto --- I forgot, would someone please backport this to 7.0 branch. I can't confirm if it work, though (non-Retina) but I assume it does :-) -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 Telesto changed: What|Removed |Added CC||xiscofa...@libreoffice.org --- Comment #49 from Telesto --- They commit has been pushed https://cgit.freedesktop.org/libreoffice/core/commit/?id=87964eb39e2668f80bcbf503d9a3b55a7f86ce28 Somehow without notification.. probably because of the missing TDF bug number in the commit title -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 --- Comment #48 from Noel Grandin --- Leo, come hang out at #libreoffice-dev on freenode IRC, and we can help you -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 --- Comment #47 from Leo Wang --- (In reply to Tor Lillqvist from comment #46) > Leo, could you please start submitting your patches through Gerrit? That is > what everybody else uses... I have done it for you a couple of times, but it > is rather tedious. I have created my Gerrit account, but failed to `git push` (403). -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 --- Comment #46 from Tor Lillqvist --- Leo, could you please start submitting your patches through Gerrit? That is what everybody else uses... I have done it for you a couple of times, but it is rather tedious. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468
--- Comment #45 from Leo Wang ---
Patch dated 2020-10-27.
1. Code style adjustments according to comments on Gerrit.
2. Small performance improvements:
- Create the CGImage based on window's color space instead of the display's.
- Set blend mode to kCGBlendModeCopy when copying bitmaps.
diff --git a/vcl/inc/quartz/salgdi.h b/vcl/inc/quartz/salgdi.h
index 8058b68378b6..0aaf71f0f839 100644
--- a/vcl/inc/quartz/salgdi.h
+++ b/vcl/inc/quartz/salgdi.h
@@ -134,6 +134,8 @@ class AquaSalGraphics : public SalGraphics
{
CGLayerHolder maLayer; // Quartz graphics layer
CGContextHolder maContextHolder; // Quartz drawing context
+CGContextHolder maBGContextHolder; // Quartz drawing context for CGLayer
+CGContextHolder maCSContextHolder; // Quartz drawing context considering
the color space
XorEmulation* mpXorEmulation;
int mnXorMode; // 0: off 1: on 2:
invert only
diff --git a/vcl/quartz/salgdicommon.cxx b/vcl/quartz/salgdicommon.cxx
index 7f96124f96ac..7c7dcac7898f 100644
--- a/vcl/quartz/salgdicommon.cxx
+++ b/vcl/quartz/salgdicommon.cxx
@@ -426,11 +426,14 @@ void AquaSalGraphics::copyArea( long nDstX, long
nDstY,long nSrcX, long nSrcY,
CGContextScaleCTM( xSrcContext, +1, -1 );
aSrcPoint.y = (nScaledSourceY + nScaledSourceHeight) - (mnHeight *
fScale);
}
+CGContextSetBlendMode(xSrcContext, kCGBlendModeCopy);
+
CGContextDrawLayerAtPoint(xSrcContext, aSrcPoint, maLayer.get());
}
// draw at new destination
const CGRect aTargetRect = CGRectMake(nScaledTargetX, nScaledTargetY,
nScaledSourceWidth, nScaledSourceHeight);
+CGContextSetBlendMode(xCopyContext, kCGBlendModeCopy);
CGContextDrawLayerInRect(xCopyContext, aTargetRect,
sSourceLayerHolder.get());
maContextHolder.restoreState();
diff --git a/vcl/quartz/salgdiutils.cxx b/vcl/quartz/salgdiutils.cxx
index 426aea29dc78..57953e536796 100644
--- a/vcl/quartz/salgdiutils.cxx
+++ b/vcl/quartz/salgdiutils.cxx
@@ -69,11 +69,28 @@ void AquaSalGraphics::SetPrinterGraphics( CGContextRef
xContext, long nDPIX, lon
void AquaSalGraphics::InvalidateContext()
{
UnsetState();
+
+CGContextRelease(maContextHolder.get());
+CGContextRelease(maBGContextHolder.get());
+CGContextRelease(maCSContextHolder.get());
+
maContextHolder.set(nullptr);
+maCSContextHolder.set(nullptr);
+maBGContextHolder.set(nullptr);
}
void AquaSalGraphics::UnsetState()
{
+if (maBGContextHolder.isSet())
+{
+CGContextRelease(maBGContextHolder.get());
+maBGContextHolder.set(nullptr);
+}
+if (maCSContextHolder.isSet())
+{
+CGContextRelease(maCSContextHolder.get());
+maBGContextHolder.set(nullptr);
+}
if (maContextHolder.isSet())
{
maContextHolder.restoreState();
@@ -119,7 +136,12 @@ bool AquaSalGraphics::CheckContext()
{
CGContextRelease(maContextHolder.get());
}
+CGContextRelease(maBGContextHolder.get());
+CGContextRelease(maCSContextHolder.get());
+
maContextHolder.set(nullptr);
+maBGContextHolder.set(nullptr);
+maCSContextHolder.set(nullptr);
maLayer.set(nullptr);
}
@@ -133,14 +155,17 @@ bool AquaSalGraphics::CheckContext()
const CGSize aLayerSize = { static_cast(nScaledWidth),
static_cast(nScaledHeight) };
const int nBytesPerRow = (nBitmapDepth * nScaledWidth) / 8;
-void* pRawData = std::malloc(nBytesPerRow * nScaledHeight);
-const int nFlags = kCGImageAlphaNoneSkipFirst;
-CGContextHolder aContextHolder(CGBitmapContextCreate(
-pRawData, nScaledWidth, nScaledHeight, 8, nBytesPerRow,
GetSalData()->mxRGBSpace, nFlags));
+int nFlags = kCGImageAlphaNoneSkipFirst |
kCGBitmapByteOrder32Host;
+maBGContextHolder.set(CGBitmapContextCreate(
+NULL, nScaledWidth, nScaledHeight, 8, nBytesPerRow,
GetSalData()->mxRGBSpace, nFlags));
-maLayer.set(CGLayerCreateWithContext(aContextHolder.get(),
aLayerSize, nullptr));
+maLayer.set(CGLayerCreateWithContext(maBGContextHolder.get(),
aLayerSize, nullptr));
maLayer.setScale(fScale);
+nFlags = kCGImageAlphaPremultipliedFirst |
kCGBitmapByteOrder32Host;
+maCSContextHolder.set(CGBitmapContextCreate(
+NULL, nScaledWidth, nScaledHeight, 8, nBytesPerRow,
GetSalData()->mxRGBSpace, nFlags));
+
CGContextRef xDrawContext = CGLayerGetContext(maLayer.get());
maContextHolder = xDrawContext;
@@ -217,8 +242,17 @@ void AquaSalGraphics::UpdateWindow( NSRect& )
const CGSize aSize = maLayer.getSizePoints();
const CGRect aRect = CGRectMake(0, 0, aSize.width,
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 --- Comment #44 from Leo Wang --- As far as I know, most Mac displays are color-managed, even very old models of notebook and workstation, which means the color space conversion is unavoidable. Also, color space conversions can be performed between two same bit-per-component formats (e.g. 8-bit SRGB and 8-bit calibrated SRGB). -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 --- Comment #43 from Tor Lillqvist --- I am not sure whether any actual significant copy of data is generated or not. Isn't CGIMage a very "lazy" class and operations on a such don't necessarily do any work or allocate any significant amounts of data unless absolutely needed? Only profiling can tell. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 --- Comment #42 from Noel Grandin --- Leo, thanks for this, nice work. But I notice we are introducing an extra copy into the hot path - what is this going to do on low end macs, where the display is likely to be 8-bit RGB already? Do we not need some kind of check for > 8 bit before doing the extra copy? -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 --- Comment #41 from Tor Lillqvist --- See https://gerrit.libreoffice.org/c/core/+/104756 I cleaned up the last bit of the patch (and a preceding line) to be more consistent (initialise both CGRect structs there the same way), and to not use the "x" prefix for something that is not a UNO reference. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 --- Comment #40 from Leo Wang --- (In reply to Tor Lillqvist from comment #39) > The patch in comment #38 replaces the ones in comment #36 and #37, right? > Will try and submit to Gerrit for you. Yes. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 --- Comment #39 from Tor Lillqvist --- The patch in comment #38 replaces the ones in comment #36 and #37, right? Will try and submit to Gerrit for you. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468
--- Comment #38 from Leo Wang ---
Further improved patch based on the color depth limit patch.
1. Improved drawing performance on 10-bit displays by avoiding multiple color
space conversions.
2. Make all drawing context bitmaps have the same color space and byte order of
the host system.
3. Fixed serious CG-related memory leak (existed no later than version 7.0)
when changing the window size.
diff --git a/vcl/inc/quartz/salgdi.h b/vcl/inc/quartz/salgdi.h
index 8058b68378b6..0aaf71f0f839 100644
--- a/vcl/inc/quartz/salgdi.h
+++ b/vcl/inc/quartz/salgdi.h
@@ -134,6 +134,8 @@ class AquaSalGraphics : public SalGraphics
{
CGLayerHolder maLayer; // Quartz graphics layer
CGContextHolder maContextHolder; // Quartz drawing context
+CGContextHolder maBGContextHolder; // Quartz drawing context for CGLayer
+CGContextHolder maCSContextHolder; // Quartz drawing context considering
the color space
XorEmulation* mpXorEmulation;
int mnXorMode; // 0: off 1: on 2:
invert only
diff --git a/vcl/quartz/salgdiutils.cxx b/vcl/quartz/salgdiutils.cxx
index 426aea29dc78..1bd3063358bf 100644
--- a/vcl/quartz/salgdiutils.cxx
+++ b/vcl/quartz/salgdiutils.cxx
@@ -69,11 +69,26 @@ void AquaSalGraphics::SetPrinterGraphics( CGContextRef
xContext, long nDPIX, lon
void AquaSalGraphics::InvalidateContext()
{
UnsetState();
+
+CGContextRelease(maContextHolder.get());
+CGContextRelease(maBGContextHolder.get());
+CGContextRelease(maCSContextHolder.get());
+
maContextHolder.set(nullptr);
+maCSContextHolder.set(nullptr);
+maBGContextHolder.set(nullptr);
}
void AquaSalGraphics::UnsetState()
{
+if (maBGContextHolder.isSet())
+{
+CGContextRelease(maBGContextHolder.get());
+}
+if (maCSContextHolder.isSet())
+{
+CGContextRelease(maCSContextHolder.get());
+}
if (maContextHolder.isSet())
{
maContextHolder.restoreState();
@@ -119,7 +134,12 @@ bool AquaSalGraphics::CheckContext()
{
CGContextRelease(maContextHolder.get());
}
+CGContextRelease(maBGContextHolder.get());
+CGContextRelease(maCSContextHolder.get());
+
maContextHolder.set(nullptr);
+maBGContextHolder.set(nullptr);
+maCSContextHolder.set(nullptr);
maLayer.set(nullptr);
}
@@ -133,14 +153,17 @@ bool AquaSalGraphics::CheckContext()
const CGSize aLayerSize = { static_cast(nScaledWidth),
static_cast(nScaledHeight) };
const int nBytesPerRow = (nBitmapDepth * nScaledWidth) / 8;
-void* pRawData = std::malloc(nBytesPerRow * nScaledHeight);
-const int nFlags = kCGImageAlphaNoneSkipFirst;
-CGContextHolder aContextHolder(CGBitmapContextCreate(
-pRawData, nScaledWidth, nScaledHeight, 8, nBytesPerRow,
GetSalData()->mxRGBSpace, nFlags));
+int nFlags = kCGImageAlphaNoneSkipFirst |
kCGBitmapByteOrder32Host;
+maBGContextHolder.set(CGBitmapContextCreate(
+NULL, nScaledWidth, nScaledHeight, 8, nBytesPerRow,
GetSalData()->mxRGBSpace, nFlags));
-maLayer.set(CGLayerCreateWithContext(aContextHolder.get(),
aLayerSize, nullptr));
+maLayer.set(CGLayerCreateWithContext(maBGContextHolder.get(),
aLayerSize, nullptr));
maLayer.setScale(fScale);
+nFlags = kCGImageAlphaPremultipliedFirst |
kCGBitmapByteOrder32Host;
+maCSContextHolder.set(CGBitmapContextCreate(
+NULL, nScaledWidth, nScaledHeight, 8, nBytesPerRow,
GetSalData()->mxRGBSpace, nFlags));
+
CGContextRef xDrawContext = CGLayerGetContext(maLayer.get());
maContextHolder = xDrawContext;
@@ -217,8 +240,13 @@ void AquaSalGraphics::UpdateWindow( NSRect& )
const CGSize aSize = maLayer.getSizePoints();
const CGRect aRect = CGRectMake(0, 0, aSize.width, aSize.height);
-
-CGContextDrawLayerInRect(rCGContextHolder.get(), aRect,
maLayer.get());
+const CGRect xRect = { CGPointZero, maLayer.getSizePixels() };
+CGContextDrawLayerInRect(maCSContextHolder.get(), xRect,
maLayer.get());
+CGImageRef img = CGBitmapContextCreateImage(maCSContextHolder.get());
+CGImageRef displayColorSpaceImage =
CGImageCreateCopyWithColorSpace(img,
CGDisplayCopyColorSpace(CGMainDisplayID()));
+CGContextDrawImage(rCGContextHolder.get(), aRect,
displayColorSpaceImage);
+CGImageRelease(img);
+CGImageRelease(displayColorSpaceImage);
rCGContextHolder.restoreState();
}
--
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468
--- Comment #37 from Leo Wang ---
Corrected patch. :-(
---
diff --git a/vcl/inc/quartz/salgdi.h b/vcl/inc/quartz/salgdi.h
index 8058b68378b6..165e704dbeb9 100644
--- a/vcl/inc/quartz/salgdi.h
+++ b/vcl/inc/quartz/salgdi.h
@@ -134,6 +134,7 @@ class AquaSalGraphics : public SalGraphics
{
CGLayerHolder maLayer; // Quartz graphics layer
CGContextHolder maContextHolder; // Quartz drawing context
+CGContextHolder maCSContextHolder; // Quartz drawing context considering
the color space
XorEmulation* mpXorEmulation;
int mnXorMode; // 0: off 1: on 2:
invert only
diff --git a/vcl/quartz/salgdiutils.cxx b/vcl/quartz/salgdiutils.cxx
index 426aea29dc78..3521dac35def 100644
--- a/vcl/quartz/salgdiutils.cxx
+++ b/vcl/quartz/salgdiutils.cxx
@@ -120,6 +120,7 @@ bool AquaSalGraphics::CheckContext()
CGContextRelease(maContextHolder.get());
}
maContextHolder.set(nullptr);
+maCSContextHolder.set(nullptr);
maLayer.set(nullptr);
}
@@ -134,13 +135,18 @@ bool AquaSalGraphics::CheckContext()
const int nBytesPerRow = (nBitmapDepth * nScaledWidth) / 8;
void* pRawData = std::malloc(nBytesPerRow * nScaledHeight);
-const int nFlags = kCGImageAlphaNoneSkipFirst;
+int nFlags = kCGImageAlphaNoneSkipFirst |
kCGBitmapByteOrder32Host;
CGContextHolder aContextHolder(CGBitmapContextCreate(
pRawData, nScaledWidth, nScaledHeight, 8, nBytesPerRow,
GetSalData()->mxRGBSpace, nFlags));
maLayer.set(CGLayerCreateWithContext(aContextHolder.get(),
aLayerSize, nullptr));
maLayer.setScale(fScale);
+pRawData = std::malloc(nBytesPerRow * nScaledHeight);
+nFlags = kCGImageAlphaNoneSkipFirst | kCGBitmapByteOrder32Host;
+maCSContextHolder.set(CGBitmapContextCreate(
+pRawData, nScaledWidth, nScaledHeight, 8, nBytesPerRow,
GetSalData()->mxRGBSpace, nFlags));
+
CGContextRef xDrawContext = CGLayerGetContext(maLayer.get());
maContextHolder = xDrawContext;
@@ -217,8 +223,13 @@ void AquaSalGraphics::UpdateWindow( NSRect& )
const CGSize aSize = maLayer.getSizePoints();
const CGRect aRect = CGRectMake(0, 0, aSize.width, aSize.height);
-
-CGContextDrawLayerInRect(rCGContextHolder.get(), aRect,
maLayer.get());
+const CGRect xRect = { CGPointZero, maLayer.getSizePixels() };
+CGContextDrawLayerInRect(maCSContextHolder.get(), xRect,
maLayer.get());
+CGImageRef img = CGBitmapContextCreateImage(maCSContextHolder.get());
+CGImageRef displayColorSpaceImage =
CGImageCreateCopyWithColorSpace(img,
CGDisplayCopyColorSpace(CGMainDisplayID()));
+CGContextDrawImage(rCGContextHolder.get(), aRect,
displayColorSpaceImage);
+CGImageRelease(img);
+CGImageRelease(displayColorSpaceImage);
rCGContextHolder.restoreState();
}
--
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468
--- Comment #36 from Leo Wang ---
The following patch which works with the color depth limit patch provides speed
improvements while keeping the color space of the internal bitmap the same as
before (SRGB). It creates a CGImage of the color space of the current display
when painting the layer to the screen context.
diff --git a/vcl/inc/quartz/salgdi.h b/vcl/inc/quartz/salgdi.h
index 8058b68378b6..165e704dbeb9 100644
--- a/vcl/inc/quartz/salgdi.h
+++ b/vcl/inc/quartz/salgdi.h
@@ -134,6 +134,7 @@ class AquaSalGraphics : public SalGraphics
{
CGLayerHolder maLayer; // Quartz graphics layer
CGContextHolder maContextHolder; // Quartz drawing context
+CGContextHolder maCSContextHolder; // Quartz drawing context considering
the color space
XorEmulation* mpXorEmulation;
int mnXorMode; // 0: off 1: on 2:
invert only
diff --git a/vcl/osx/saldata.cxx b/vcl/osx/saldata.cxx
index 14124e4b00f8..66b4e6a4bed9 100644
--- a/vcl/osx/saldata.cxx
+++ b/vcl/osx/saldata.cxx
@@ -52,7 +52,8 @@ SalData::SalData()
mpFirstPrinter( nullptr ),
mpFontList( nullptr ),
mpStatusItem( nil ),
-mxRGBSpace( CGDisplayCopyColorSpace( CGMainDisplayID() ) ),
+mxRGBSpace( CGColorSpaceCreateWithName(kCGColorSpaceSRGB) ),
+//mxRGBSpace( CGDisplayCopyColorSpace( CGMainDisplayID() ) ),
mxGraySpace( CGColorSpaceCreateWithName(kCGColorSpaceGenericGrayGamma2_2)
),
maCursors(),
mbIsScrollbarDoubleMax( false ),
diff --git a/vcl/quartz/salgdiutils.cxx b/vcl/quartz/salgdiutils.cxx
index 426aea29dc78..3521dac35def 100644
--- a/vcl/quartz/salgdiutils.cxx
+++ b/vcl/quartz/salgdiutils.cxx
@@ -120,6 +120,7 @@ bool AquaSalGraphics::CheckContext()
CGContextRelease(maContextHolder.get());
}
maContextHolder.set(nullptr);
+maCSContextHolder.set(nullptr);
maLayer.set(nullptr);
}
@@ -134,13 +135,18 @@ bool AquaSalGraphics::CheckContext()
const int nBytesPerRow = (nBitmapDepth * nScaledWidth) / 8;
void* pRawData = std::malloc(nBytesPerRow * nScaledHeight);
-const int nFlags = kCGImageAlphaNoneSkipFirst;
+int nFlags = kCGImageAlphaNoneSkipFirst |
kCGBitmapByteOrder32Host;
CGContextHolder aContextHolder(CGBitmapContextCreate(
pRawData, nScaledWidth, nScaledHeight, 8, nBytesPerRow,
GetSalData()->mxRGBSpace, nFlags));
maLayer.set(CGLayerCreateWithContext(aContextHolder.get(),
aLayerSize, nullptr));
maLayer.setScale(fScale);
+pRawData = std::malloc(nBytesPerRow * nScaledHeight);
+nFlags = kCGImageAlphaNoneSkipFirst | kCGBitmapByteOrder32Host;
+maCSContextHolder.set(CGBitmapContextCreate(
+pRawData, nScaledWidth, nScaledHeight, 8, nBytesPerRow,
GetSalData()->mxRGBSpace, nFlags));
+
CGContextRef xDrawContext = CGLayerGetContext(maLayer.get());
maContextHolder = xDrawContext;
@@ -217,8 +223,13 @@ void AquaSalGraphics::UpdateWindow( NSRect& )
const CGSize aSize = maLayer.getSizePoints();
const CGRect aRect = CGRectMake(0, 0, aSize.width, aSize.height);
-
-CGContextDrawLayerInRect(rCGContextHolder.get(), aRect,
maLayer.get());
+const CGRect xRect = { CGPointZero, maLayer.getSizePixels() };
+CGContextDrawLayerInRect(maCSContextHolder.get(), xRect,
maLayer.get());
+CGImageRef img = CGBitmapContextCreateImage(maCSContextHolder.get());
+CGImageRef displayColorSpaceImage =
CGImageCreateCopyWithColorSpace(img,
CGDisplayCopyColorSpace(CGMainDisplayID()));
+CGContextDrawImage(rCGContextHolder.get(), aRect,
displayColorSpaceImage);
+CGImageRelease(img);
+CGImageRelease(displayColorSpaceImage);
rCGContextHolder.restoreState();
}
--
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 --- Comment #35 from Michael Meeks --- Not read it in a long time; but assuming the OS/X backend does like the gtk3 and headless backends - and keeps a back-buffer for the whole window around as well as tracking damage to do incremental rendering - possibly switching the back-buffer to the display format might help subsequent blitting of that ... just a thought. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 --- Comment #34 from Tor Lillqvist --- But it isn't only about the test. LibreOffice itself must also continue working and show colours as before. If we start claiming to the OS that the windows and bitmaps we use are in a wide-gamut colour space, but still use RGB values in them that are in sRGB, won't the colours look all wrong? If a document uses an 8 bits per channel RGB colour (0, 255, 0), that means the colour is the green primary of sRGB (which is the implicit default colour space), doesn't it? And if that colour then is used as such in a pixmap claimed to be in the display's native wide-gamut colour space, and drawn to a window that also uses the same wide-gamut colourspace, it will be shown as a much different green, as the green primary of the wide-gamut colour space. Or am I missing something? -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 --- Comment #33 from Leo Wang --- (In reply to Tor Lillqvist from comment #32) > > I think the test needs to be improved so that it is aware of the color > > value shift due to the nature of color space difference. > > Maybe, but surely also other code all over the place (slight exaggeration) > would need to be adjusted, too, if the colour space used to display LO's > windows were a device-dependent, potentially wide gamut, colour space. As it > is (now with the change reverted), everything is sRGB. Currently the test unit creates a bitmap, draws a point with specific color, gets the pixel's color value and compares against the original value. This only works when there is only one color space. Maybe we can add a "hidden" preference item to let the user choose? Without a complete rewrite of the renderer, it is very difficult to make use of the GPU: all bitmap drawing works have to be done with CPU, and it is hard to predict what color space CGLayer determines to blend all the layers to generate the final bitmap. PS: with all the 3 patches to "consistentize" the color spaces, on my Mac LibreOffice retrieves 20-25fps for text, spreadsheets and simple presentations. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 --- Comment #32 from Tor Lillqvist --- > I think the test needs to be improved so that it is aware of the color value > shift due to the nature of color space difference. Maybe, but surely also other code all over the place (slight exaggeration) would need to be adjusted, too, if the colour space used to display LO's windows were a device-dependent, potentially wide gamut, colour space. As it is (now with the change reverted), everything is sRGB. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 137468] Severe performance degradation on a macOS with 10-bit displays
https://bugs.documentfoundation.org/show_bug.cgi?id=137468 Leo Wang changed: What|Removed |Added Summary|Severe performance |Severe performance |degradation on a macOS with |degradation on a macOS with |a 5K display|10-bit displays --- Comment #31 from Leo Wang --- (In reply to Telesto from comment #30) > Thanks for all the effort Leo! Sounds promising (not that I'm able to asses > code ;-). I think will make a group of people really happy: bug 113104 I don't have other Macs, so please let me know what happens on non-10-bit displays. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
