On pc Debian x86-64 with master sources updated today, I could reproduce this.

I didn't notice anything specific on console.

I tried to bibisect, but I don't kwow how to test it:
- click on row header 2 (for example)
- move cursor on the cell area of row 2
- drag & drop that row down --> the row data is moving down

I missed something?

My build was fresh, like 1 day old, and yesterday bisect was older.
So we need 24.2 repo update to see if reproducible.

I build LibreOffice with latest updates from master, and no problem with Calc.
Are my steps wrong? (see comment 2)

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 64ccc089c1e6bf82ef10a0dd4768fdff83af55b5
CPU threads: 16; OS: Linux 6.2; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded

(In reply to Timur from comment #5)
> Created attachment 190825 [details]
> Video
> 
> This should be obvious, if reproducible.

Exactly, but I don't reproduce

with
Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: d646341e5ddc625d9cf69777b4be174aebb43700
CPU threads: 16; OS: Linux 6.2; UI render: default; VCL: x11
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded

nor with
Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: d646341e5ddc625d9cf69777b4be174aebb43700
CPU threads: 16; OS: Linux 6.2; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded

So, this is not in bibisect build, just local debug build.

I updated today the bibisect repo, was downloading new updates, but still don't repro.

(In reply to Timur from comment #0)
> [...] Cannot move selected row in 24.2. [...]
> Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
> Build ID: c32bf48b7446808ffc47472021ec32cb7c70eea7
I checked out the bibisect repo at c32bf48b7446808ffc47472021ec32cb7c70eea7 and could not reproduce.

No repro either in a recent daily build:

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: baecfd21797310bb15ab98ca3962445d99e397db
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

I did however notice a small delay in displaying the icon that denotes moving a row, so if I drag quickly then stop moving, the move is not effective when releasing (no target row highlighted, no arrows on the icon). But that's obviously something different to what you show in the video.

Now, I tested in a debug build and I can reproduce. Feels like a perf issue: if I keep the mouse button pressed for a long time it eventually changes icon and highlights the target row. Release, wait, and data is moved.
Even just row selection is sluggish. I have to wait 3 seconds before the selection changes to another row.

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 3aca2d9776a871f15009a1aa70628ba3a03ee147
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

Same issue with gen VCL plugin.
Columns don't have the same issue.

I'd think this is related to switching to 16k columns, so the amount of data to move is 16x as it used to be before, and a debug build is obviously not optimized for performance.

I can't tell whether this needs improvement or could be further improved.

(In reply to Aron Budea from comment #10)
> I'd think this is related to switching to 16k columns

If that's the case, the behavior should be already noticed in LO 7.4, when the 16384 columns were introduced. ATM this is reported against LO 24.2. Timur?

I see no difference with 16k option or without 16k: 1st time I move row after loading, it lags 5-6 secs, but later I cannot move it at all.

(In reply to Timur from comment #12)
> I see no difference with 16k option or without 16k: 1st time I move row
> after loading, it lags 5-6 secs, but later I cannot move it at all.

My intention was for someone to test with older versions, before and after the official/default introduction of 16k rows in LO 7.4.

I wasn't aware that the 2nd (consecutive) move was behaving differently/worse than the 1st; maybe I missed that detail from prior comments.

Now my test...


Since the introduction of 16384 columns in LO 7.4, there seems to be some (minor?) additional lag when moving a row (in comparison to LO 7.3), but the lag is _much_ more notable in LO 24.2.

Additionally, until LO 7.6, while moving the selected row/area (dragging the mouse but before releasing the button) we can see an edge/border indicating the destination area of the move. In contrast, in LO 24.2, such border over the to-be-destination area (either an entire row or any other selected area/cell) is not seen (although my 24.2 alpha is several weeks old ATM, so YMMV).

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: c0c8cffd3541e3cd616c96791b04e7ebf2b2ed03
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-US (es_AR); UI: en-US
Calc: CL threaded

Created attachment 192006 [details]
Windows Performance Analyzer output

I took a perf trace under Windows using the Windows Performance Recorder UI tool with CPU Usage collection selected.  I've attached the output which shows the code is spending at least 15 seconds (3 intervals of almost 5 seconds each) doing sclo.dll!ScColContainer::resize which just calls "reserve" on a std::vector container.  I don't know why moving a row has anything to do with resizing columns, but maybe someone more familiar with the code can determine the problem.

(In reply to Matt K from comment #14)
> Created attachment 192006 [details]
> Windows Performance Analyzer output
> 
> I took a perf trace under Windows using the Windows Performance Recorder UI
> tool with CPU Usage collection selected.  I've attached the output which
> shows the code is spending at least 15 seconds (3 intervals of almost 5
> seconds each) doing sclo.dll!ScColContainer::resize which just calls
> "reserve" on a std::vector container.  I don't know why moving a row has
> anything to do with resizing columns, but maybe someone more familiar with
> the code can determine the problem.

That sounds exactly like the bibisect result I got for bug 159131, so can Timur or others still repro after Noel's fix? Noel does say in the fixing commit: "I'm not sure why the above commit causes trouble on Windows, but not Linux"

This was very slow for me in GTK and now it less slow, like 2 secs, which is accepratable for debug build, but I am not sure if good for a normal use, should be checked in a release.
That bisected commit is from 7.5 but with installed LO 7.5.9 I see no delay, even those 2 secs.

I also repro about a 2 sec delay on Windows with the fix on a debug build, which is better than the 10+ sec delay that was there before.

An aside comment (but maybe not _that_ aside)...

FWIW, there was some performance issue that received some kind of patch and was later reverted, and applied again with some modification, only to be later reverted again [1]. This back and forth is around versions 7.4 to 7.6 and master (during 24.2 dev), so the _specific_ version/build that is tested for this report tdf#158167 might be relevant (with or without that patch applied/reverted).

The only reason I mention this here is because we are talking about performance under certain circumstances. The original reasons that triggered each of the lags/crashes and the respective patches might not be related to each other at all, but the possible delays (or improvements) in each test case might be wrongly attributed to some assumed proposed solution while in fact the resulting behavior might be a consequence of something else, unrelated.

IOW, seeing delays/lags in one version but not in the other, or in both (7.6.x vs 24.2.dev) while testing the reported behavior might be related to diverse factors, including the inclusion of a patch that was later reverted (twice) during the relevant development cycle.

Whether the (reverted) patch is actually of any influence for the reported behavior in this tdf#158167, I have no idea.

[1]: <https://bugs.documentfoundation.org/show_bug.cgi?id=157042#c32>

That 10 sec looked Major, now 2 sec seems High-Normal.