This is kind of expected. Think about the raster framing needed to scroll the view ports. Each "view" gets calculated, but then they are streamed one view at a time. With the Vulkan, each view (even though a vector rendering) must be cached.

IIUC with skia raster framing the "views" are just being cached, with vector framing they get recalculated (though faster HA)--the resulting "scroll" appears choppy.

Additionally, older less capable GPU and limited memory can make the frames being calculated appear to be choppy/slow.  More modern GPU with plenty of graphics RAM can do a better job.

Also with
Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: ad5cb7e99f574c17811ef7d5419b35a95ed82696
CPU threads: 8; OS: macOS 14.7.4; UI render: Skia/Metal; VCL: osx
Locale: nl-NL (nl_NL.UTF-8); UI: en-US
Calc: threaded

fine with
Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: c69b16a0f859d71a101e2c138887e7975ec71e2a
CPU threads: 8; OS: macOS 14.7.4; UI render: Skia/Metal; VCL: osx
Locale: nl-NL (nl_NL.UTF-8); UI: en-US
Calc: threaded

Also with
Version: 25.2.0.3 (X86_64) / LibreOffice Community
Build ID: e1cf4a87eb02d755bce1a01209907ea5ddc8f069
CPU threads: 8; OS: macOS 14.7.4; UI render: Skia/Metal; VCL: osx
Locale: nl-NL (nl_NL.UTF-8); UI: en-US
Calc: threaded

Bisected to: d75f72f99cc5a5e408f7e8a76bae3e32fc37c91b is the first bad commit
commit d75f72f99cc5a5e408f7e8a76bae3e32fc37c91b
Author: libreoffice <libreoffice@libreoffices-MacBook-Air.local>
Date:   Sat Dec 21 08:31:44 2024 +0100

    source c585b697b583fa0f8cdadeab594c31d270367ba7
    
    source c585b697b583fa0f8cdadeab594c31d270367ba7

 .../Contents/Frameworks/libvclplug_osxlo.dylib     | Bin 1051808 -> 1051808 bytes
 LibreOffice.app/Contents/Resources/setuprc         |   2 +-
 LibreOffice.app/Contents/Resources/versionrc       |   2 +-
 3 files changed, 2 insertions(+), 2 deletions(-)

Created attachment 200532 [details]
Example file

File used for the bibisect.

(In reply to Telesto from comment #4)
>     source c585b697b583fa0f8cdadeab594c31d270367ba7

I can confirm that disabling throttling of Skia/Metal flushing stops this bug from occurring in my local master build. Unfortunately, that causes the Calc and Impress bugs in tdf#163945 to reappear:

Version: 25.8.0.0.alpha0+ (AARCH64) / LibreOffice Community
Build ID: 648d97619c921d2f94a91e2932712063ca37646f
CPU threads: 8; OS: macOS 15.4.1; UI render: Skia/Metal; VCL: osx
Locale: en-CA (en_CA.UTF-8); UI: en-US
Calc: threaded

What is surprising to me is that the purpose of commit c585b697b583fa0f8cdadeab594c31d270367ba7 was to throttle the rate of Skia/Metal flushing to avoid the type of "flooding the Metal drawing queue" problem described in comment 1. But for this bug, throttling is the problem so now I have to figure out how to bypass the throttling for this bug but not for tdf#163945.

Patrick Luby committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/a24789f747dc998bd4fd1c0110a89e791ee051c2

tdf#166258 Refactor throttling of Skia/Metal flushes

It will be available in 25.8.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

I have committed a fix for this bug and the fix should be in tomorrow's (28 April 2025) nightly master builds:

https://dev-builds.libreoffice.org/daily/master/current.html

Note for macOS testers: the nightly master build installer does *not* overwrite any LibreOffice official versions. Instead, it will be installed as a separate application called "LibreOfficeDev" in the /Applications folder.

Because this is a "test" build, you will need to do the following steps before you launch the LibreOfficeDev application:

1. Go to the Finder and navigate to the /Applications/Utilities folder
2. Launch the "Terminal" application
3. Paste the following command in the Terminal application window and press the Return key to execute the command:

   xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app

Working fine
Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 9f308ba42f44e7d8e2f73a92923b0374e39083aa
CPU threads: 8; OS: macOS 14.7.4; UI render: Skia/Metal; VCL: osx
Locale: nl-NL (nl_NL.UTF-8); UI: en-US
Calc: threaded

I reimplemented my fix for this bug because the last group of fixes caused tdf#163945 to reoccur. So can anyone test that this bug does not reoccur in the current nightly master build? The commit should be in today's (15 May 2025) nightly master builds:

https://dev-builds.libreoffice.org/daily/master/current.html

Note for macOS testers: the nightly master build installer does *not* overwrite any LibreOffice official versions. Instead, it will be installed as a separate application called "LibreOfficeDev" in the /Applications folder.

Because this is a "test" build, you will need to do the following steps before you launch the LibreOfficeDev application:

1. Go to the Finder and navigate to the /Applications/Utilities folder
2. Launch the "Terminal" application
3. Paste the following command in the Terminal application window and press the Return key to execute the command:

   xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app

Working fine
Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 5c7b3f5dc1f14081eed380999dc029a500784d55
CPU threads: 8; OS: macOS 14.7.4; UI render: Skia/Metal; VCL: osx
Locale: nl-NL (nl_NL.UTF-8); UI: en-US
Calc: threaded

Thanks for the fix!