Description: . Steps to Reproduce: Open file with images, for example from here: https://nextcloud.documentfoundation.org/s/ERX39EPf88LHn7A scroll with mouse Actual Results: white lines across the image Expected Results: no lines Reproducible: Always User Profile Reset: No Additional Info: .
Created attachment 203381 [details] printscreen
This seems to have begun at the below commit in bibisect repository/OS linux-64-26.2. Adding Cc: to Caolán McNamara ; Could you possibly take a look at this one? Thanks fb13c6920d050c1360a90355b7bac548d241c830 is the first bad commit commit fb13c6920d050c1360a90355b7bac548d241c830 Author: Jenkins Build User <tdf@maggie.tdf> Date: Fri Aug 22 13:26:29 2025 +0200 source a6dc33e5b4af22ef150ca328ad67132e85ec3dbe 190054: Resolves: tdf#156297 restore copy area optimization | https://gerrit.libreoffice.org/c/core/+/190054
Created attachment 203397 [details] recording of what I see Given that the report is for linux and the code itself is probably only used for non-gtk I imagine you see it in gen (or qt). But trying gen here locally it seems fine for me so I can't reproduce.
Created attachment 203420 [details] screenshot I succeded to see the lines just once, after the first loading of the document, but when I changed the zoom they just disapear. After that no repro. I tried with safe mode. Nothing. Nothing in 25.8, nothing in master with X11. Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1873b492f0c5a3520cd1c7de3bd2d7758d5df529 CPU threads: 16; OS: Linux 6.14; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Ok, tried again with master, and I made a screenshot, to prove. Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1873b492f0c5a3520cd1c7de3bd2d7758d5df529 CPU threads: 16; OS: Linux 6.14; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Zooming in/out is making the effect to disapear.
Created attachment 203421 [details] video testing the bug I will mark the bug as new, being confirmed, and bibisected.
(In reply to Caolán McNamara from comment #3) > Created attachment 203397 [details] > recording of what I see > > Given that the report is for linux and the code itself is probably only used > for non-gtk I imagine you see it in gen (or qt). But trying gen here locally > it seems fine for me so I can't reproduce. Hello, I've tested with GTK3.
Created attachment 204607 [details] JF's sample file to reproduce the bug Hi Caolán, please try this sample odt file I'm attaching. I suspect it will allow you to reproduce the issue, on page 3. It is 100% reproducible for me. The trick is anchor images "as character", instead of anchoring images "to paragraph" (page 2).
Created attachment 204608 [details] JF's video demonstration reproducing the bug This is a video comparing the paragraph-anchored image on page 2 not triggering the issue, vs the image on page 3 anchored "as character" that easily triggers the issue. This was observed on Fedora 42's Wayland GNOME 48.7 session with Intel Kabylake graphics and an external mouse with discrete scrollwheel, on: Version: 25.8.3.2 (X86_64) / LibreOffice Community Build ID: 8ca8d55c161d602844f5428fa4b58097424e324e CPU threads: 8; OS: Linux 6.17; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Flatpak
I would also note: I don't think this was introduced in the 25.8-to-26.2 cycle; in my case this almost certainly predates version 25.8, I think I've been experiencing this issue for many months, if not years.
One more troubleshooting observation: this happens particularly if, in the general Options dialog, in "LibreOffice Writer > View > View" the "Smooth scroll" checkbox is disabled. If I check "[x] Smooth scroll" and restart the app (to ensure it has applied the setting), then the issue does not occur, at least on the GTK3 version.
That is reproducible for me with that example, under gtk3 and under wayland.
I'm not 110% sure about the "smooth scroll" setting eliminating the symptom by the way, I suspect there might be some "luck" component to this (but I'm glad that my sample document provides a higher probability of encountering the problem).
I find that export DISABLE_SYSTEM_DEPENDENT_PRIMITIVE_RENDERER=1 makes the white line problem go away for me. Initially my thought was that the white line was an ancient problem that has reemerged, while now my feeling is that it is a more more recent issue with the SDPR thing. Perhaps an issue with scaling, pixel snapping or an inconsistency in considering the last row/column of Rectangles as included or not.
@armin: FYI. I feel there is some pixel-snapping or slight scaling issue at play here with SDPR