The last known working commit for devs to use is the following:

commit 3b544a311d6ab22e1e04c45a841d5f24d5c6b325
Author: Luboš Luňák <l.lunak@collabora.com>
Date:   Thu Jan 21 12:56:48 2021 +0100

    fix incorrect palette color indexes

Can not confirm, multiple functional TB77 builds after the 12 Mar 2021 f9cf66b commit ref'd.

On Windows 10 (20H2) with Intel HD Graphics 620 and Skia (Vulkan or raster only) rendering.

Please post details from Help about (or the , and content of the skia.log from user profile cache.


=-testing-=
Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: bdbb5d0389642c0d445b5779fe2a18fda3e4a4d4
CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

RenderMethod: vulkan
Vendor: 0x8086
Device: 0x5916
API: 1.2.151
Driver: 0.402.591
DeviceType: integrated
DeviceName: Intel(R) HD Graphics 620
Denylisted: no

Regression does not appear in latest version of bibisect-win64-7.2 and must be younger.

I'm not able to repro after updating master to latest which has the following commit:

commit e18b743a840475cfbdfba437a1edf8677a5f93bd (HEAD -> master, origin/master, origin/HEAD)
Author: Jim Raykowski <raykowj@gmail.com>
Date:   Thu Mar 11 10:31:46 2021 -0900

    tdf#140936 statusbar selection mode control improvements

    - shows different image for each selection mode
    - tooltip indicates the current selection mode and mouse click hint
    - replaces left-click cycle selection mode with context menu popup

    Change-Id: Ieb2662de99cf42d4ada4c1a590bebc8363861c7b
    Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112367
    Tested-by: Jenkins
    Reviewed-by: Rizal Muttaqin <rizmut@libreoffice.org>

Details:
Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: e18b743a840475cfbdfba437a1edf8677a5f93bd
CPU threads: 12; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

RenderMethod: raster
Compiler: Clang

Well great that it works for you now. But reality is this is invalid--we can't tell what may have caused regression or subsequently been fixed with your builds and os/DE for handling the TB nightlies.  The bisections provided are suspect, and the Tinderbox builds are proven functional.

I'd believe a Skia related issue on your build/testing system, but at this point I guess the WFM is fine.

Should it reappear, reopen. But with more complete details.

Repros again after updating master, which has the following commit:

commit fde3b0e07eaf86ed4e16326de323f79db706e8f2 (origin/master, origin/HEAD)
Author: Eike Rathke <erack@redhat.com>
Date:   Mon Mar 29 21:04:04 2021 +0200

    Sheet names can contain parentheses and blanks

    ... so search for the very first occurrence of " (" and not the
    last, and also not any ")" but it has to be the last character in
    the Name Box UI representation of sheet-local scope names so check
    just that.

    Change-Id: I0b63688432f891ee779e3e32017def78b021e470
    Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113327
    Reviewed-by: Eike Rathke <erack@redhat.com>
    Tested-by: Jenkins

Details:
Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: dede17b4e3712f9a1cd6c602fd4d73ddcf36a3f0
CPU threads: 12; OS: Windows 10.0 Build 19041; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

RenderMethod: vulkan
Vendor: 0x10de
Device: 0x1b06
API: 1.2.155
Driver: 461.368.0
DeviceType: discrete
DeviceName: GeForce GTX 1080 Ti
Denylisted: no

I tried building the 2 most recent commits, and the UI worked when the Help page had "Calc: threaded" and failed when it had "Calc: CL".  This value changed for me when I deleted both the "cache" and "user" directories under "core/instdir" and restarted soffice.exe.

WORKED:
Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: fde3b0e07eaf86ed4e16326de323f79db706e8f2
CPU threads: 12; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

RenderMethod: raster
Compiler: Clang


FAILED:
Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: e511a32b70119a1a7ccc762ffbf0d814cf603a2b
CPU threads: 12; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

RenderMethod: raster
Compiler: Clang

I updated the bibisect-win64-7.2 repo and it now repros there too.  Here is the output from "git bisect":
 cbaecb94d25c1a094063e70e568ef7491b484f07 is the first bad commit
commit cbaecb94d25c1a094063e70e568ef7491b484f07
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Fri Mar 26 13:20:53 2021 -0700

    source f9cf66b39ea00afc66ae79ca46cd9071f3598cb8

    source f9cf66b39ea00afc66ae79ca46cd9071f3598cb8


And here is the Help output for that commit (which is bad):

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: f9cf66b39ea00afc66ae79ca46cd9071f3598cb8
CPU threads: 12; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

RenderMethod: raster
Compiler: Clang


And here is the Help output for the commit before that one (which works):

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 3b544a311d6ab22e1e04c45a841d5f24d5c6b325
CPU threads: 12; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

RenderMethod: raster
Compiler: Clang


Here is the bisect log:
$ git bisect log
# bad: [2f992f005e53cd40edc45787d93101d2422a23d6] source 3453f2f8fce9e69cd9f2a2c6f3d7171b6e59f674
# good: [0de175072f79362baeb83b6733b9300d4de5fba4] source 738bcf5e9a8c443d60c29c3a8068e8c16c72638a
git bisect start 'master' 'oldest'
# good: [30f2a6dcb14a05e3e598f4ad780309e7055992e1] source f6a38df16cb2749f007a644db3d0dee829960114
git bisect good 30f2a6dcb14a05e3e598f4ad780309e7055992e1
# good: [59fa5eb8c1fd4920c959596b83780ad8ae65764c] source f5dc6b11d2218d94c9effe7a1ab418d0133da5e3
git bisect good 59fa5eb8c1fd4920c959596b83780ad8ae65764c
# good: [468c422d56b6b46cca426bc3876df3f1b783fd5c] source 7246c1b4971e780be8d027de5171f42cc0749c16
git bisect good 468c422d56b6b46cca426bc3876df3f1b783fd5c
# bad: [2eec2abdf914c6e409599e5b994c3255c6e0ecf2] source d2475f85bf4f0015007746d6af5dd5baaee09566
git bisect bad 2eec2abdf914c6e409599e5b994c3255c6e0ecf2
# bad: [1b072876b59eea7e88e4a0c767efdecce5ab307c] source c0d223f7036263d3e7012d497ea71d4722052927
git bisect bad 1b072876b59eea7e88e4a0c767efdecce5ab307c
# good: [fa9d2a0dbd6fbc7df12fa009f776e9b74a92e782] source 2c818b70a4e8bd98fa1cce80ea9b7fb408a88401
git bisect good fa9d2a0dbd6fbc7df12fa009f776e9b74a92e782
# good: [303f126230cce9e24c36137269b9f4c51d9e5046] source a7c0039542fb015e34c56ec25f92f59a4c6ba1fa
git bisect good 303f126230cce9e24c36137269b9f4c51d9e5046
# bad: [9f4d2ad1817779e707370db0de0fad42f685dc19] source 6e4238018bf0408f2961e5708212e09a8c3597dc
git bisect bad 9f4d2ad1817779e707370db0de0fad42f685dc19
# good: [22ed2a8ee2f99134405fc3fe88b1aa0ade4b9624] source 3b544a311d6ab22e1e04c45a841d5f24d5c6b325
git bisect good 22ed2a8ee2f99134405fc3fe88b1aa0ade4b9624
# bad: [3545f31bb3778cffeb5d63262af68fd5746efa39] source 31442054520cf0a263cc17e157cfa102cff8ef6a
git bisect bad 3545f31bb3778cffeb5d63262af68fd5746efa39
# bad: [2ede49c9792819ba1f16ce742099b2a269a44506] source 83bee81c5228e8950c3c9da46e050936c19858e7
git bisect bad 2ede49c9792819ba1f16ce742099b2a269a44506
# bad: [cbaecb94d25c1a094063e70e568ef7491b484f07] source f9cf66b39ea00afc66ae79ca46cd9071f3598cb8
git bisect bad cbaecb94d25c1a094063e70e568ef7491b484f07
# first bad commit: [cbaecb94d25c1a094063e70e568ef7491b484f07] source f9cf66b39ea00afc66ae79ca46cd9071f3598cb8

Reopened is when there was a fix that didn't work, not case here,never confirmed.
I don't understand why so many commits, earlier ones are obviously wrong.

hello Matt K,
it's not possible you get a different result every time you bisect it.
Please, clean the user profile 'rm -rf instdir/user/' on every step...

(In reply to Timur from comment #9)
> I don't understand why so many commits, earlier ones are obviously wrong.

I don't understand this comment; the commit I posted in the Description is the bad commit.

(In reply to Xisco Faulí from comment #10)
> it's not possible you get a different result every time you bisect it.

The first time I tried, the repo was not updated to include the bad commit.  The second time I tried, I updated the repo which now includes the bad commit. So, it's expected that the second time would see the failure.

> Please, clean the user profile 'rm -rf instdir/user/' on every step...

OK, I tried this and I get the same result:
 cbaecb94d25c1a094063e70e568ef7491b484f07 is the first bad commit
commit cbaecb94d25c1a094063e70e568ef7491b484f07
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Fri Mar 26 13:20:53 2021 -0700

    source f9cf66b39ea00afc66ae79ca46cd9071f3598cb8

    source f9cf66b39ea00afc66ae79ca46cd9071f3598cb8

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: f9cf66b39ea00afc66ae79ca46cd9071f3598cb8
CPU threads: 12; OS: Windows 10.0 Build 19041; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

RenderMethod: vulkan
Vendor: 0x10de
Device: 0x1b06
API: 1.2.155
Driver: 461.368.0
DeviceType: discrete
DeviceName: GeForce GTX 1080 Ti
Denylisted: no


$ git bisect log
# bad: [2f992f005e53cd40edc45787d93101d2422a23d6] source 3453f2f8fce9e69cd9f2a2c6f3d7171b6e59f674
# good: [0de175072f79362baeb83b6733b9300d4de5fba4] source 738bcf5e9a8c443d60c29c3a8068e8c16c72638a
git bisect start 'master' 'oldest'
# good: [30f2a6dcb14a05e3e598f4ad780309e7055992e1] source f6a38df16cb2749f007a644db3d0dee829960114
git bisect good 30f2a6dcb14a05e3e598f4ad780309e7055992e1
# good: [59fa5eb8c1fd4920c959596b83780ad8ae65764c] source f5dc6b11d2218d94c9effe7a1ab418d0133da5e3
git bisect good 59fa5eb8c1fd4920c959596b83780ad8ae65764c
# good: [468c422d56b6b46cca426bc3876df3f1b783fd5c] source 7246c1b4971e780be8d027de5171f42cc0749c16
git bisect good 468c422d56b6b46cca426bc3876df3f1b783fd5c
# bad: [2eec2abdf914c6e409599e5b994c3255c6e0ecf2] source d2475f85bf4f0015007746d6af5dd5baaee09566
git bisect bad 2eec2abdf914c6e409599e5b994c3255c6e0ecf2
# bad: [1b072876b59eea7e88e4a0c767efdecce5ab307c] source c0d223f7036263d3e7012d497ea71d4722052927
git bisect bad 1b072876b59eea7e88e4a0c767efdecce5ab307c
# good: [fa9d2a0dbd6fbc7df12fa009f776e9b74a92e782] source 2c818b70a4e8bd98fa1cce80ea9b7fb408a88401
git bisect good fa9d2a0dbd6fbc7df12fa009f776e9b74a92e782
# good: [303f126230cce9e24c36137269b9f4c51d9e5046] source a7c0039542fb015e34c56ec25f92f59a4c6ba1fa
git bisect good 303f126230cce9e24c36137269b9f4c51d9e5046
# bad: [9f4d2ad1817779e707370db0de0fad42f685dc19] source 6e4238018bf0408f2961e5708212e09a8c3597dc
git bisect bad 9f4d2ad1817779e707370db0de0fad42f685dc19
# good: [22ed2a8ee2f99134405fc3fe88b1aa0ade4b9624] source 3b544a311d6ab22e1e04c45a841d5f24d5c6b325
git bisect good 22ed2a8ee2f99134405fc3fe88b1aa0ade4b9624
# bad: [3545f31bb3778cffeb5d63262af68fd5746efa39] source 31442054520cf0a263cc17e157cfa102cff8ef6a
git bisect bad 3545f31bb3778cffeb5d63262af68fd5746efa39
# bad: [2ede49c9792819ba1f16ce742099b2a269a44506] source 83bee81c5228e8950c3c9da46e050936c19858e7
git bisect bad 2ede49c9792819ba1f16ce742099b2a269a44506
# bad: [cbaecb94d25c1a094063e70e568ef7491b484f07] source f9cf66b39ea00afc66ae79ca46cd9071f3598cb8
git bisect bad cbaecb94d25c1a094063e70e568ef7491b484f07
# first bad commit: [cbaecb94d25c1a094063e70e568ef7491b484f07] source f9cf66b39ea00afc66ae79ca46cd9071f3598cb8

No repro. 
Did you reset user profile and git reset also? 
It's not probable that there's a bug that 2 of us and many other don't reproduce, or we would have an avalanche of reports. 
Please try to figure out what is wrong, profile or some option in Calc, Options -  View maybe. 
Please do not respond until you pinpoint the cause.

It appears to be a bug in my video driver for NVIDIA graphics card; I uninstalled my video driver, restarted, and deleted user profile and it works.  Then, I updated the latest graphics driver for NVIDIA GeForce GTX 1080 Ti (version 465.89), restarted, and deleted user profile and the bug happens again.  All of my other apps work fine with the NVIDIA driver, and I have an installation of LibreOffice 7.1.1.2 that works fine.

(In reply to Timur from comment #12)
> Did you reset user profile and git reset also? 
> Please try to figure out what is wrong, profile or some option in Calc,
> Options -  View maybe. 

I tried resetting user profile, git reset, disabling and enabling all checkboxes under "Graphics Output" under Options->view, and disabling OpenCL under Options.  I also restarted in Safe Mode and disabled hardware acceleration, and the bug still happens with the NVIDIA driver.

Is there any way to work around this for this specific driver (and maybe other NVIDIA drivers are impacted too)?  I can stop using the NVIDIA driver, but then parts of my OS display are cut off and it's hard to use.

Is there anything else I can do to help debug it?

@Matt,

"The LibreOffice UI doesn't show when trying to create new documents..."

That is a little too indescript. A couple of screen clips please.

There were instances during the OpenGL based era, when specific drivers would result in GUI menus not displaying their text. And it would be a GPU/driver related issue for AMD, Intel or nVidia graphics. 

But, that using default GDI rendering -- deselecting the OpenGL rendering from the Tools -> Options -> View dialog (or via Denylist handling for the GPU, os, or driver) restores visibility.

I can't recall the same visual glitches with menus have happened in the Skia rendering era, but it is feasible.

Helps to remember LO implements multiple rendering modes:

1.  CPU only, default GDI  (all uncheckeds on Tools -> Options -> View panel)

2.  default GDI with CPU controlled Hardware Acceleration (the one box checked)

3. either of the above with the anti-aliasing box checked

4. Skia based accelerated rendering raster only (with both Skia boxes checked)

5. Skia based accelerated rendering with Vulkan--next gen OpenGL--(the raster rendering box unchecked)

For 7.2 OpenGL rendering calls have now been removed. And the Denylist / Allowlist handling only affects the Skia rendering use of Vulkan or raster only calls.

So, with that in mind please rethink your testing.  Each of the rendering configurations, against each of the discrete nVidia GPU's drivers, or any additional GPU / driver you test (e.g. an onboard Intel).

No issue with
 
RenderMethod: vulkan
Vendor: 0x10de
Device: 0x1380
API: 1.2.142
Driver: 457.120.0
DeviceType: discrete
DeviceName: GeForce GTX 750 Ti
Denylisted: no

and  Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 5707ec3303f8215af91aac7d7f7cc29bf67b6c99
CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

and when I upgrade to latest nVidia driver 465-89 with Skia log showing:

RenderMethod: vulkan
Vendor: 0x10de
Device: 0x1380
API: 1.2.168
Driver: 465.356.0
DeviceType: discrete
DeviceName: NVIDIA GeForce GTX 750 Ti
Denylisted: no

Still no visible issues with this nVidia GPU or Windows build (1909)

Created attachment 170910 [details]
Screenshot of No UI/gray menu drop down

I isolated the cause to the following user config file:
instdir/user/registrymodifications.xcu

I saved a "good" version of the file that worked after uninstalling the NVIDIA driver, and I kept the "good" version after re-installing the NVIDIA driver and the bug goes away -- so it may not be a driver issue.  To isolate the cause, I diff'd the "good" and "bad" .xcu file and found the cause was the following line:

<item oor:path="/org.openoffice.Setup/Office/Factories/org.openoffice.Setup:Factory['com.sun.star.frame.StartModule']"><prop oor:name="ooSetupFactoryWindowAttributes" oor:op="fuse"><value>...</value></prop></item>

After deleting that line from the config and restarting LibreOffice, the bug re-appears, and inspecting the .xcu file shows new/different values for this item.

(In reply to V Stuart Foote from comment #14)
> That is a little too indescript. A couple of screen clips please.

Added screenshot attachment

> So, with that in mind please rethink your testing.  Each of the rendering
> configurations, against each of the discrete nVidia GPU's drivers, or any
> additional GPU / driver you test (e.g. an onboard Intel).

Here is the results of my testing:

1.  CPU only, default GDI  (all uncheckeds on Tools -> Options -> View panel)
	- NVIDIA GeForce GTX 1080 Ti version 465.89: bad
	- Microsoft Basic Display Adapter version 10.0.19041.1: works
	
2.  default GDI with CPU controlled Hardware Acceleration (the one box checked)
	- NVIDIA GeForce GTX 1080 Ti version 465.89: bad
	- Microsoft Basic Display Adapter version 10.0.19041.1: works
	
3. either of the above with the anti-aliasing box checked
	- NVIDIA GeForce GTX 1080 Ti version 465.89: bad
	- Microsoft Basic Display Adapter version 10.0.19041.1: works
	
4. Skia based accelerated rendering raster only (with both Skia boxes checked)
	- NVIDIA GeForce GTX 1080 Ti version 465.89: bad
	- Microsoft Basic Display Adapter version 10.0.19041.1: works
	
5. Skia based accelerated rendering with Vulkan--next gen OpenGL--(the raster rendering box unchecked)
	- NVIDIA GeForce GTX 1080 Ti version 465.89: bad
	- Microsoft Basic Display Adapter version 10.0.19041.1: works

There are other nVidia bugs. Did you search them? 
Except they are with LO 7.0, see if the same issue.

(In reply to Matt K from comment #17)
...

> > So, with that in mind please rethink your testing.  Each of the rendering
> > configurations, against each of the discrete nVidia GPU's drivers, or any
> > additional GPU / driver you test (e.g. an onboard Intel).
> 
> Here is the results of my testing:
> 
> 1.  CPU only, default GDI  (all uncheckeds on Tools -> Options -> View panel)
> 	- NVIDIA GeForce GTX 1080 Ti version 465.89: bad
> 	- Microsoft Basic Display Adapter version 10.0.19041.1: works
> ...

Unclear, had you reconnected displays to an on-motherboard integrated GPU (so Intel or AMD)? Or were they still attached to the discrete nVidia GPU graphics card, but using the Windows provided driver?

Can not confirm on Windows 10 (20H2) with nVidia Quadro K2000 

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: bdbb5d0389642c0d445b5779fe2a18fda3e4a4d4
CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

existing nVidia driver -- no issues

RenderMethod: vulkan
Vendor: 0x10de
Device: 0xffe
API: 1.2.142
Driver: 457.36.0
DeviceType: discrete
DeviceName: Quadro K2000
Denylisted: no

updated 2021-04-02, no issues with latest nVidia driver for this GPU

RenderMethod: vulkan
Vendor: 0x10de
Device: 0xffe
API: 1.2.155
Driver: 461.368.0
DeviceType: discrete
DeviceName: Quadro K2000
Denylisted: no

I did more testing and found that it may be a bug in Windows.  When I changed Windows OS Settings->Display->Scale and Layout->setting anything above 100% causes the bug to not repro AND after setting to a value higher than 100%, Windows caches some values and resetting back to 100% did not repro anymore.  I had to uninstall the driver, and reinstall the driver for the issue to repro again, and do not modify any Windows OS settings (leave scaling at default 100%).  So, in your testing, you may have some Windows cached value and need to uninstall the graphics driver first.

That said, I updated my repo to latest on master again and the bug seems to not repro on recent builds (~april 2), but there were previously over 2 weeks of changes where the issue was reproing.  I will try to isolate the change where the behavior disappeared.

(In reply to V Stuart Foote from comment #20)
> Unclear, had you reconnected displays to an on-motherboard integrated GPU (so Intel or AMD)? Or were they still attached to the discrete nVidia GPU graphics card, but using the Windows provided driver?

I did not change any connections, everything was still attached to the nVidia graphics card and was using the Windows provided driver.

(In reply to Timur from comment #18)
> There are other nVidia bugs. Did you search them? 
> Except they are with LO 7.0, see if the same issue.

I searched all bugs with nvidia in the comment for all 7.* versions and the only bug I found that may be related is Bug 132847, but that does not seems as severe as this one (even that one redraws the screen when user clicks over bad UI area).

(In reply to Matt K from comment #21)
> That said, I updated my repo to latest on master again and the bug seems to
> not repro on recent builds (~april 2)

The first change where the bug disappears is:

commit e8d93ae128f7947e64eb8c849b4af9c54c9dd7a5 (HEAD)
Author: Caolán McNamara <caolanm@redhat.com>
Date:   Thu Apr 1 10:31:27 2021 +0100

    Resolves: tdf#141258 turn scrollbars on/off once per layout loop
    ...
    Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113447

(In reply to Matt K from comment #22)
> The first change where the bug disappears is:
> 
> commit e8d93ae128f7947e64eb8c849b4af9c54c9dd7a5 (HEAD)

That commit is very unlikely to affect the problems described in this bugreport. This is most likely an external problem, with the driver presumably, and your testing just randomly does or does not trigger the problem. Can you reliably reproduce the problem when going to the commit before this one and not reproduce it when going to this commit?

(In reply to Luboš Luňák from comment #23)
> (In reply to Matt K from comment #22)
> > The first change where the bug disappears is:
> > 
> > commit e8d93ae128f7947e64eb8c849b4af9c54c9dd7a5 (HEAD)
> 
> Can you reliably reproduce the problem when going to the commit
> before this one and not reproduce it when going to this commit?

Yes, I cannot reproduce the problem for this commit, but I can reproduce it every time for the commit before that which is:
 a2b1ee5b1229a5efdc90b9495cf4b6f56e3207b1

It still does not reproduce on latest master anymore.

I don't follow this bug but per last comment it's WFM. 

It you think there should be done something here, please:
1. make single summary comment 
2.hide irrelevant comments with tag "obsolete" 
3.set Unconfirmed and explain what should be confirmed.

Created attachment 171142 [details]
Screenshot of severe UI glitch after scrolling left/right

On latest master, there is now a severe UI glitching problem (see screenshot) and a crash/abort, which is not exactly the original issue but just as severe.

To reproduce the UI glitching:
1. Ensure the following options are set in Tools->Options->View: Skia based accelerated rendering with Vulkan--next gen OpenGL--(the raster rendering box unchecked)
2. Open Calc, select a cell, then scoll left/right quickly until the UI glitch appears

To reproduce the crash/abort:
1. Ensure the following options are set in Tools->Options->View: Skia based accelerated rendering with Vulkan--next gen OpenGL--(the raster rendering box unchecked)
2. Open Calc and try to resize the window smaller horizontally and observe app freezes then terminates

The abort happens at the following code location: vcllo.dll!SkiaSalGraphicsImpl::postDraw() Line 446

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 88ca6d7834a9d710dc124ee845fd3c270e33b59a
CPU threads: 12; OS: Windows 10.0 Build 19041; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

RenderMethod: vulkan
Vendor: 0x10de
Device: 0x1b06
API: 1.2.168
Driver: 465.356.0
DeviceType: discrete
DeviceName: NVIDIA GeForce GTX 1080 Ti
Denylisted: no

*** This bug has been marked as a duplicate of bug 141680 ***