external/skia/swap-buffers-rect.patch.1 | 21 ++++++++++++++++++--- sw/source/core/docnode/section.cxx | 4 +++- 2 files changed, 21 insertions(+), 4 deletions(-)
New commits: commit 32eb29377c5bbf6a965357756d2813add2789053 Author: Patrick Luby <[email protected]> AuthorDate: Wed Nov 20 20:16:30 2024 -0500 Commit: Patrick Luby <[email protected]> CommitDate: Thu Nov 21 14:46:32 2024 +0100 tdf#163945 present drawable immediately It seems that -[MTLCommandBuffer presentDrawable:] doesn't immediately replace the previous drawable on screen so I assume that there is some default minimum display time for drawables. LibreOffice only invokes this method in a timer so let LibreOffice control the rate of window updates by presenting the drawable right now. Change-Id: Ibd8d72bd6ea0303f9582264791cc4356bda62c13 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176879 Reviewed-by: Patrick Luby <[email protected]> Tested-by: Jenkins diff --git a/external/skia/swap-buffers-rect.patch.1 b/external/skia/swap-buffers-rect.patch.1 index 0b02be761a50..0451725fdf22 100644 --- a/external/skia/swap-buffers-rect.patch.1 +++ b/external/skia/swap-buffers-rect.patch.1 @@ -11,9 +11,9 @@ diff -ur skia.org/tools/window/MetalWindowContext.h skia/tools/window/MetalWindo bool fValid; diff -ur skia.org/tools/window/MetalWindowContext.mm skia/tools/window/MetalWindowContext.mm ---- skia.org/tools/window/MetalWindowContext.mm 2024-10-05 18:16:04.521814026 +0200 -+++ skia/tools/window/MetalWindowContext.mm 2024-10-05 18:17:31.670443188 +0200 -@@ -193,7 +193,7 @@ +--- skia.org/tools/window/MetalWindowContext.mm 2024-11-15 19:32:58 ++++ skia/tools/window/MetalWindowContext.mm 2024-11-20 19:02:09 +@@ -153,13 +153,21 @@ return surface; } @@ -22,6 +22,21 @@ diff -ur skia.org/tools/window/MetalWindowContext.mm skia/tools/window/MetalWind id<CAMetalDrawable> currentDrawable = (id<CAMetalDrawable>)fDrawableHandle; id<MTLCommandBuffer> commandBuffer([*fShared->fQueue commandBuffer]); + commandBuffer.label = @"Present"; + +- [commandBuffer presentDrawable:currentDrawable]; ++ // tdf#163945 present drawable immediately ++ // It seems that -[MTLCommandBuffer presentDrawable:] doesn't ++ // immediately replace the previous drawable on screen so I ++ // assume that there is some default minimum display time for ++ // drawables. ++ // LibreOffice only invokes this method in a timer so let ++ // LibreOffice control the rate of window updates by presenting ++ // the drawable right now. ++ [commandBuffer presentDrawable:currentDrawable atTime:CACurrentMediaTime()]; + [commandBuffer commit]; + // ARC is off in sk_app, so we need to release the CF ref manually + CFRelease(fDrawableHandle); diff -ur skia.org/tools/window/unix/RasterWindowContext_unix.cpp skia/tools/window/unix/RasterWindowContext_unix.cpp --- skia.org/tools/window/unix/RasterWindowContext_unix.cpp 2024-10-05 18:16:04.521814026 +0200 +++ skia/tools/window/unix/RasterWindowContext_unix.cpp 2024-10-05 18:18:49.554847490 +0200 commit fbfbd2f51ebc5ab239d06ded7931214b1c84a5fd Author: Michael Stahl <[email protected]> AuthorDate: Wed Nov 20 19:30:54 2024 +0100 Commit: Michael Stahl <[email protected]> CommitDate: Thu Nov 21 14:46:29 2024 +0100 sw: fix hiding/unhiding section via condition The problem was that when un-hiding a section, table rows that contained only empty paragraphs were not reformatted and remained at height 0. It turns out that the table row that became visible did so because the cells had a VertOrientation different from NONE and so SwContentNotify::ImplDestroy() invalidated the cells' printarea. However, the real problem isn't in the layout code at all, as it then turns out that the reason why anything is reformatted at all is that there are docinfo fields on the same page as the section and also in the paragraphs at the start of the section, and these get invalidated somehow after unhiding the section. Unhiding the section didn't actually invalidate anything in the layout because in ImplSetHiddenFlag() no change is detected, and that is because the section was first hidden by removing its (false) condition, which calls SwSection::SetSectionData() and that didn't call ImplSetHiddenFlag(), again relying on docinfo field update to trigger the relayouting. Change-Id: Ie5d9e4d5a0467c17c662f20f8d54aa6b22b382da Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176914 Tested-by: Jenkins Reviewed-by: Michael Stahl <[email protected]> diff --git a/sw/source/core/docnode/section.cxx b/sw/source/core/docnode/section.cxx index c539c7531dc8..d9ac1d35ddd6 100644 --- a/sw/source/core/docnode/section.cxx +++ b/sw/source/core/docnode/section.cxx @@ -254,12 +254,14 @@ SwSection::~SwSection() void SwSection::SetSectionData(SwSectionData const& rData) { bool const bOldHidden( m_Data.IsHidden() ); + bool const bOldCondHidden{m_Data.IsCondHidden()}; m_Data = rData; // The next two may actually overwrite the m_Data.m_bProtect or EditInReadonly Flag // in Modify, which should result in same flag value as the old code! SetProtect(m_Data.IsProtectFlag()); SetEditInReadonly(m_Data.IsEditInReadonlyFlag()); - if (bOldHidden != m_Data.IsHidden()) // check if changed... + if (bOldHidden != m_Data.IsHidden() + || bOldCondHidden != m_Data.IsCondHidden()) // check if changed... { ImplSetHiddenFlag(m_Data.IsHidden(), m_Data.IsCondHidden()); }
