fix(remote-gui): Windows repaint fixes — log-view blanking (#445) + list rows blanking on scroll/keyboard (#478)#477
Merged
Conversation
…eeze/Thaw (amule-project#445) amule-project#471 tried to fix the "log view goes blank on every new line" Windows regression by thawing before scrolling, but it made no difference: the AppendText still ran while the control was frozen. Appending to a frozen wxTE_RICH2 (RichEdit) on Windows leaves its line/scroll metrics stale, so on Thaw the view renders blank with the newest line pinned to the top until a manual scroll forces a recompute. The Freeze()/Thaw() that amule-project#451 wrapped the per-poll appends in is the actual culprit, not the scroll order. Drop the Freeze()/Thaw() and append on a live control (as the pre-amule-project#451 code did). Keep the two real wins from amule-project#451: the daemon's 5000-lines-per-poll cap and the conditional SetDefaultStyle, plus one coalesced ShowPosition per poll instead of per line (m_logBatching still suppresses the per-line scroll). The per-line SetDefaultStyle was the dominant first-sync cost, so responsiveness is retained without the frozen-append rendering corruption. macOS/GTK recompute metrics regardless and were unaffected either way.
got3nks
changed the title
got3nks
force-pushed
the
fix/remote-log-blank-freeze
branch
2 times, most recently
from
fc4f3e1 to
0996407
Compare
amule-project#478) amule-project#348 replaced the vendored wxListMainWindow::OnScroll's synchronous HandleOnScroll(event) with event.Skip() -- HandleOnScroll became a private member in wx 3.3.3, so the macOS/Linux CI (on wx 3.3.x) stopped compiling. On wxMSW the resulting deferred-scroll path (wxScrollHelperBase::HandleOnScroll -> ScrollWindow) blits the retained rows and only invalidates the newly exposed strip, which is then left unpainted: rows go blank on mouse-wheel, scrollbar and pagination scrolling until a redraw is forced. Verified in the wx 3.2.10 and 3.3.x sources that the scroll+repaint mechanism is identical, so this is a wxMSW platform behavior, not a wx-version one. Rather than gate on platform or wx version (both fragile -- the former needs the now-private HandleOnScroll, the latter breaks once Windows ships wx 3.3.3), reimplement the synchronous scroll using only the public wxScrollHelper API (GetViewStart / GetScrollLines / GetScrollPageSize / Scroll), mirroring HandleOnScroll()/CalcScrollInc(): translate the scroll event into a target position in scroll units and scroll to it. Factor the "scroll + repaint" sequence into a shared ScrollListTo(x, y) helper (Update() to flush pending paints so the blit is clean, Scroll(), then ResetVisibleLinesRange() so the exposed rows repaint) and route both OnScroll (scrollbar/wheel) and MoveToItem (keyboard nav) through it. This also fixes the keyboard HOME/END/PgUp/PgDn blanking, which was the same bug from a different path: MoveToItem only reset the visible-line range after Scroll() under __WXMAC__, so on Windows the range stayed stale and keyboard scrolls came up blank. The reset now runs on every platform via the shared helper, and the old __WXMAC__-only workaround is gone. Not skipping the event means the base scroll helper won't also scroll, so no double-scroll. Works on every supported wx (>= 3.2.0) and every platform with no version or platform guard; compiles against wx 3.3.3. Refs amule-project#478
got3nks
force-pushed
the
fix/remote-log-blank-freeze
branch
from
0996407 to
e8230f1
Compare
got3nks
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two Windows-only aMuleGUI repaint fixes reported by @ghysler.
1. Log view blanks on every new line (#445) — confirmed fixed
Follow-up to #471. #471 thawed the control before scrolling, but
AppendTextstill ran while the control was frozen; on Windows, appending to a frozenwxTE_RICH2leaves its line/scroll metrics stale, so onThaw()the view blanks until a manual scroll. Fix: drop theFreeze()/Thaw()and append on a live control, keeping the #451 wins (daemon 5000-lines/poll, conditionalSetDefaultStyle, one coalescedShowPositionper poll). ghysler confirmed fixed.2. List rows disappear on scroll — mouse and keyboard (#478)
Regression from #348, which replaced the vendored
wxListMainWindow::OnScroll's synchronousHandleOnScroll(event)withevent.Skip()(wx 3.3.3 madeHandleOnScrollprivate, breaking the macOS/Linux CI). On wxMSW the resulting deferred-scroll path (wxScrollHelperBase::HandleOnScroll→ScrollWindow) blits the retained rows and only invalidates the newly-exposed strip, which is then left unpainted — rows blank on wheel/scrollbar/pagination scrolling. Verified in both the wx 3.2.10 and 3.3.x sources that the scroll+repaint mechanism is identical, so it's a wxMSW platform behavior, not a wx-version one.Rather than gate on platform or wx version (the former needs the now-private
HandleOnScroll; the latter breaks once Windows ships wx 3.3.3), reimplement the synchronous scroll using only the publicwxScrollHelperAPI (GetViewStart/GetScrollLines/GetScrollPageSize/Scroll), mirroringHandleOnScroll()/CalcScrollInc().The "scroll + repaint" sequence is factored into a shared
ScrollListTo(x, y)helper (Update()to flush pending paints so the blit is clean →Scroll()→ResetVisibleLinesRange()so the exposed rows repaint), and bothOnScroll(scrollbar/wheel) andMoveToItem(keyboard nav) go through it. That also fixes the keyboard HOME/END/PgUp/PgDn blanking — same bug, different path:MoveToItemonly reset the visible-line range afterScroll()under__WXMAC__, so on Windows it stayed stale and keyboard scrolls came up blank. The reset now runs on every platform via the shared helper.Not skipping the event means the base helper won't also scroll (no double-scroll). Works on every supported wx (≥ 3.2.0) and every platform, no version or platform guard, and compiles against wx 3.3.3.
Both are client-side, GUI-rendering only — no daemon or EC protocol change.