https://bugs.documentfoundation.org/show_bug.cgi?id=173033
Bug ID: 173033
Summary: Writer stops repainting under Wayland (Qt6) after a
heavy main-thread burst (e.g. autosave); only recovers
on a window-activation event
Product: LibreOffice
Version: 26.2.5.2 release
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Writer
Assignee: [email protected]
Reporter: [email protected]
Description:
Under native Wayland (KWin 6.7.4, Qt 6.11.1, VCL `qt6` plugin), the Writer
window
completely stops emitting `wl_surface.frame()` requests for several seconds
(13-17 s in two captured instances), even though the process stays alive and
keeps processing
keyboard/mouse input normally (the document is still being modified, and
commands such as Save execute correctly). The window only repaints again once
an
`xdg_toplevel.configure` event arrives (typically triggered by a window
activation-state change, e.g. switching focus away and back) — at that point LO
repaints the entire surface in one go, not incrementally.
This is not a KWin event-delivery problem (keyboard/mouse events do arrive and
get
processed) nor a `frame` callback left unanswered by the compositor (verified:
no
`frame()` request was outstanding during the stall — LO simply stopped issuing
new
ones). It points to a bug in VCL/Qt6's internal repaint scheduling under
Wayland,
apparently triggered by a burst of heavy work on the main thread (autosave/ODF
export in one of the two captured instances; layout/word-count-type CPU bursts
in the other).
Captured with `WAYLAND_DEBUG=1` (client protocol trace, timestamped in real
time) cross referenced against a custom sampler that logs CPU/rchar/wchan of
the main thread plus the active window (via a small KWin script), dumping a
full `eu-stack` on suspected stalls.
Steps to Reproduce:
1. Open a large .odt document with many UNO-driven edits accumulated over a
long
session (in our case: a legal document with citations inserted via the
Zotero
LibreOffice integration, which uses UNO text cursors heavily).
2. Work with normal typing for 10-15 minutes, letting periodic autosave fire
(or edit text in a way that forces layout recalculation across a lot of
content).
3. Watch for the window becoming visually unresponsive shortly after a CPU
burst on the main thread (autosave or layout work), while it keeps accepting
input (e.g. clicking Save still saves the file, even though the toolbar button
doesn't visually highlight).
4. Switch focus to another window and back.
Actual Results:
The Writer window stops repainting (document content, toolbar highlight state,
cursor blink) for 13-17 seconds, despite continuing to process input correctly.
Recovery only happens when a window-activation event occurs (switching focus
away and back), at which point the entire window surface repaints at once,
showing everything that had accumulated during the stall.
Expected Results:
The window keeps repainting continuously while the document is being edited,
regardless of autosave or layout-recalculation bursts on the main thread.
Reproducible: Sometimes
User Profile Reset: Yes
Additional Info:
AI helped me to identify and report (actually written by AI: hope it helps).
Reproducible: Sometimes (not yet deterministic; reproduced twice in one session
on a
large, heavily-edited document, both times shortly after a main-thread CPU
burst)
Version: 26.2.5.2 620(Build:2)
OS: Garuda Linux (Arch), kernel 7.1.6-1-cachyos, KDE Plasma / KWin 6.7.4,
native
Wayland session, Qt 6.11.1 (qt6-base, qt6-wayland)
Additional Info:
Case 1 (13.3 s stall):
Last `wl_surface#40.frame()` request before the gap received its `done`
normally. No
new `frame()` request was issued until 13.3 s later, when this sequence arrived
and
immediately unstuck the window:
xdg_toplevel#79.configure(1600, 868, array[4])
xdg_surface#78.configure(...)
-> xdg_surface#78.ack_configure(...)
-> wl_surface#40.frame(new id wl_callback#45)
-> wl_surface#40.attach(wl_buffer#91, 0, 0)
-> wl_surface#40.damage_buffer(0, 0, 3200, 1736) <- entire surface
-> wl_surface#40.commit()
wl_callback#45.done(...)
Immediately before the gap, the main thread showed several CPU bursts (up to
220%
total CPU) consistent with layout/word-count work.
Case 2 (17.0 s stall):
Last surface activity before the gap was the text-cursor caret blink (a
VCL-internal
timer, independent of typing) — after that, not even the caret blink triggered
a new
repaint request. Immediately before this gap (5 seconds earlier), the sampler
had
captured a 5-second 100%-CPU main-thread hot loop whose full `eu-stack` trace
unambiguously shows an autosave operation:
AutoRecovery::implts_timerExpired
-> SfxObjectShell::SaveAsOwnFormat
-> SwXMLExport::collectAutoStyles
-> SwDoc::cleanupUnoCursorTable() [bottleneck: walks the UNO text-cursor
table
once per exported paragraph]
The stall ended the moment the user's keyboard focus left the LO surface
(switching to another application) and a new `xdg_toplevel.configure` arrived
shortly after:
wl_keyboard#30.leave(...) <- focus leaves LO
...
xdg_toplevel#79.configure(1600, 868, array[4])
-> wl_surface#40.frame(new id wl_callback#51)
-> wl_surface#40.damage_buffer(0, 0, 3200, 1736) <- entire surface again
-> wl_surface#40.commit()
No Zotero window was focused at any point in the 6 minutes preceding this
second
stall — it followed normal typing, right after the autosave. This suggests the
document's heavy use of the Zotero integration (many UNO text cursors from
citation
insertion) is not a direct trigger of the repaint bug itself, but likely makes
the
preceding main-thread bursts (autosave export, word-count across mixed locales)
more
expensive and therefore the stall more frequent.
Checked for duplicates: bug 160565 / 160864 ("freezes after save as" / "screen
stops
refreshing after save") looked like a strong match by title, but its root cause
(QWidget::winId() native-handle issue) was confirmed to reproduce only on
Plasma+X11,
not Wayland, and was fixed in 24.8.0/24.2.4 — unrelated to this report, which
is
Wayland-native and reproduces on a current version.
Attachments available on request: full `WAYLAND_DEBUG=1` protocol trace
(timestamped) and sampler log with full `eu-stack` dumps for both instances.
--
You are receiving this mail because:
You are the assignee for the bug.
