I don't think dev version a suitable for this kind of comparisions.

@m.a.riosv: do you think dev. version is remarkable slow regarding debug info which will be off for release, or do you think we shall wait with the analysis of bugs until after the release? then all the time first releases will be crap ...

It's my personal impression, so do what you like.

BTW you have not share the file to test.

@m.a.riosv: 
just take a blank sheet and scroll down as described ... compare ver. 6.2.8.2 against actual master (win, i didn't test lin) and you'll see the difference ...

with 7.0.0.0.a0+ master it's about 62 seconds to scroll from A1 to AMJ1 with the cursor key while holding down shift to mark the range, and about 50 seconds to scroll back from AMJ2 to A2 without shift, 

both tasks finished in 6.2.8.2 in ~16 seconds ... 

i think the users will not be happy when such delays are implemented in the release

heh, it's a Skia problem here (possible)

I got 20 000 cells for 20 sec with  UI render: Skia/Raster;

and 28 000 cells with UI render: default; VCL: win; 

in version

Version: 7.0.0.0.alpha0+ (x64)
Build ID: 6388c578c672690fff662cb04b6a0436cd742f37
CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: Skia/Raster; VCL: win; 
Locale: ru-RU (ru_RU); UI-Language: en-US
Calc: threaded

@Roman: 

Skia/Raster: may be, but most probably not the only source, 

your performance default vs. Skia Raster has about 40% difference, 

my measuring 6.2 vs. 7.0 has about 400% difference, 

40% performance difference is something to care for, 

1:4 slowdown is an issue, 

if of interest: my screen: 4k in 3840x2160 mode, my graphics: nvidia Quadro M4000M, font sizing 225%, 

performance difference significantly lower when switching to 1920x1080 mode with 125% font size, ~43.000 rows / 20 sec. with 6.2 vs. ~33.000 rows / 20 sec. with 7.0, 

thus a 'high-res' or 'non-default-scaling' problem with 7.0 or skia?

So, try test in latest today's 7.0 build with and without skia on HiDPI screen with 4k resolutuon, please

Please try a more recent build.

with 'skia' off (tools - options - libreofficedev - view - use skia for all rendering) both (6.2 and 7.0) are head to head, as well in 1920 as in 3840 mode, 

@roman: thks for the tip to look for that, 

skia disables 'hardware acceleration' - hardware acceleration didn't make a big difference itself, but skia does, but only in high-res modes, 

thus a skia-with-high-res or skia-with-non-default-scaling problem, 

the 7.0 ver. i tested is about two days old, will try again later,

hand stopped thus not very precise measurements with ver: 

Version: 7.0.0.0.alpha0+ (x64)
Build ID: 61d8d991a27c3bfe70e3b8d3b4ce4d8a41d18d2d
CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-US
Calc: 

count of rows for scrolldown with <page-down> and <shift> within 20 seconds, 'keyrate 200 15', thus 66 keystrokes per second after 0,2 seconds delay, 
4k screen, 3840x2160 mode, user defined font size 225%, 
graphics card nvidia Quadro M4000M, 
LO fullscreen, zoom factor 100%, 46 rows per page visible, empty sheet: 

use OpenGL for all rendering:    ~53.000 rows, 
no significant change with: 
'use anti aliasing' active 

no view option set:              ~38.000 rows, 

use hardware acceleration:       ~31.500 rows, 

use Skia for all rendering:      ~13.000 rows, 
no significant change with 
'ignore Skia blacklist', 
'force Skia software rendering', 
or both, 

it is possible to activate openGL and! Skia, it's as slow as Skia, 

hope it helps ...

I can reproduce a difference, but only if Skia doesn't use Vulkan. Given that you still use Windows 7, I assume you have also old graphics drivers? Is there any chance you could try with something that has Vulkan support? The card should be capable of that.

@Luboš: thanks for the hint, tested with nvidia 'enterprise' drivers from 12'2019,
acc. to download page they support vulkan 1.1, i couldn't find any settings or info in the control panel, former drivers have been from 2015, LO 7.0a0+: 

use openGL for all rendering: ~41k rows/20sec, 

no accelerators activated:    ~31k rows/20sec, 

use Skia for all rendering:   ~11k rows/20sec, 

high-res mode, thus skia still with problem, 

didn't test 1920 mode, but was already fast with skia and old drivers, 

unfortunately the driver has degraded the good performance of openGL 

:-(

but it's still usable and much better than skia, 

hope that helps?

(In reply to Roman Kuznetsov from comment #6)
> heh, it's a Skia problem here (possible)
> 
> I got 20 000 cells for 20 sec with  UI render: Skia/Raster;
> 
> and 28 000 cells with UI render: default; VCL: win; 
> 
> in version
> 
> Version: 7.0.0.0.alpha0+ (x64)
> Build ID: 6388c578c672690fff662cb04b6a0436cd742f37
> CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: Skia/Raster; VCL:
> win; 
> Locale: ru-RU (ru_RU); UI-Language: en-US
> Calc: threaded

I got

18 000 selected cells for 20 sec in

Версия: 7.0.0.0.alpha0+ (x64)
ID сборки: f265b14d6f8e3e63260b3c8ecce48d4251288fea
Потоков ЦП: 4; ОС: Windows 10.0 Build 17763; Отрисовка ИП: Skia/Vulkan; VCL: win; 
Локаль: ru-RU (ru_RU); Язык интерфейса: ru-RU
Calc: threaded

but i got the same result in the same build without Skia or OpenGL

and the same result I got with OpenGL >_<

possibly it linked with hardware and video drivers ? Or may be it matters  version of Windows 10

Here I have 

DriverVersion: 24.20.100.6286
DriverDate: 8-15-2018
DeviceID: PCI\VEN_8086&DEV_591B&SUBSYS_1A101043&REV_04
AdapterVendorID: 0x8086
AdapterDeviceID: 0x591b
AdapterSubsysID: 0x1a101043
DeviceKey: System\CurrentControlSet\Control\Video\{50593AB0-5855-11E9-A9D9-E7305D07F358}\0000
DeviceString: Intel(R) HD Graphics 630

as said: i had significant differences with different drivers / options, 

mostly in high res mode, 

skia 12'2019 was not really fast but usable, 

but the driver paket gave me a 'black screen' on restart, 

thus i'm back to 2015 drivers and 'openGL', 

thanks for the hint with skia, 

will look again later, actually no prio, 

reg,. 

b.

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