Files
status-app/storybook/qmlTests/tests/tst_SectionPanelLoaderGeometry.qml
T
Alex Jbanca 754276d853 perf(wallet): build the wallet section around what the user is waiting for
A wallet section activation built everything it would ever need before it
showed anything: both panels inline, both detail views, every row of two
lists synchronously, and a set of subtrees that exist for cases that almost
never occur. This reorders that around a single rule - build what is on
screen first, build the rest in the incubation controller's metered bites,
and build the rest of the rest only when something asks for it.

Lists fill preemptibly. A ListView refill is one uninterruptible call inside
the window's polish phase, and QQuickItemView creates visible delegates with
AsynchronousIfNested - so a list first laid out after its enclosing Loader is
already Ready builds every visible row synchronously. On a warm load that was
one 34.7ms GUI-thread block against a 3.2ms budget for the assets list, and
8.7-13.5ms of post-content polish across both lists. The assets and accounts
delegates become TokenDelegateShell and WalletAccountDelegateShell: an Item
carrying the row's geometry and its placeholder tiles, with the real row
behind a nested asynchronous Loader. The refill builds shells; the rows
incubate afterwards.

Row height is the shell's, not the content's. StatusListItem.implicitHeight
is Math.max(64, titleArea.height + 16), and both a token row and an account
row resolve to that 64px floor, which is what placeholderHeight is.
tst_TokenDelegateShell and tst_WalletAccountDelegateShell gate the two
staying equal, so a change that makes a row taller fails a test rather than
moving contentHeight and the scroll position mid-fill. Each placeholder
mirrors the skeleton the per-tab loader showed a moment earlier, so the two
loading states read as one handoff.

Subtrees built for the exceptional case are latched off. The token row's two
warning buttons, the asset detail's four chain-tag warning buttons, its
header community tag and its "Minted by" tile were all built unconditionally
and merely hidden. Each now sits behind the condition that used to drive
`visible`. AssetsDetailsHeader loses its `communityTag` alias, which existed
only so callers could reach in and set the tag's contents; it takes
communityName/communityImage and builds the tag itself.

The two detail views move behind async Loaders keyed on the stack index. The
token to show becomes state held in `d` and bound into the view rather than
assigned into it, so a second click landing mid-incubation wins without a
queue-and-replay; the resets that hung off onVisibleChanged hang off
onActiveChanged, which fires on the same edges.

Panels build in the order the user sees them. WalletLayout declared both
panels as plain object bindings, so activation built LeftTabView and the
centre StackView inline and the chrome's two PanelSwapGates could not fire
independently - they opened 5ms apart because both panel properties resolve
when WalletLayout completes. Each panel now sits behind its own async Loader
with its own readiness, the primary one first, and once a skeleton is on
screen with no panel switch running the primary panel is built synchronously:
the pacing exists to protect section-switch animations, and here the only
thing a synchronous block could stutter is the skeleton it replaces.

Wrapping the panels in Loaders exposed three geometry defects. A Loader
reports its item's implicit size as its own, so the centre StackView's
content width propagated into the chrome and pushed the panel past the right
edge on a narrow screen; the loaders are bound to the chrome's geometry for
the unparented phase, the stack no longer anchors to its loader, and the side
inset moves onto the content where it belongs.

Panel geometry is coalesced across a rotation. A device rotation walks the
window through nine sizes over ~430ms and LayoutItemProxy forwarded every one
to the section's panels - a full relayout of a populated subtree each time -
and parked a panel at a degenerate box for ~148ms on the portrait/landscape
handoff. SectionPanelSlot replaces the panel proxies in both sub-layouts and
publishes the box each slot will give its panel, which is also what a section
building panels outside the tree needs: the centre slot cannot be guessed, as
it is short by the header and footer and narrow by the left column in
landscape. Wallet and chat both pre-size their incubating panels to it.

Two fixes fall out of that work. BaseProxyPanel looked its SwipeView page up
at a fixed implicitIndex, but SwipeView indices close up as pages come and
go, so hiding the right panel with no left panel present silently left its
page in the view, still swipeable; it now looks the page up by identity.
SectionPanelSlot also has to be listed in statusq.qrc - without it the type
is absent from the binary's resources, StatusSectionLayout becomes
unavailable and the UI process dies precompiling AppMain.

Measured on a whale profile, Release, arms alternated between rounds:

  warm t_first_asset_row       119-159ms -> 51-74ms
  warm max_stall_ms             31.7-42.6 -> 17.2-26.3ms
  section ready                     631ms -> 207ms
  visible panel promoted            609ms -> 338ms
  cold: skeleton shown -> visible  2272ms -> 1836ms
  objects_total (cold)               4602 -> 3344   (-27%)
  objects_settled                    9569 -> 8297   (-13%)
  token row QObjects                  326 -> 279
  panel geometry distinct sizes    24 -> 5 centre, 19 -> 2 left
  degenerate 0x0 box written    12 occurrences -> 0

Device numbers are only comparable once the app has settled; a run taken
while startup backend work is still in flight measured 925ms for a path that
measures ~520ms settled.

Measurements come from an offscreen storybook wallet bench that is not part
of this PR; see branch `feat/storybook-wallet-loader`.
2026-08-23 09:40:36 +03:00

194 lines
7.3 KiB
QML

import QtQuick
import QtTest
import QtQuick.Controls
import StatusQ.Layout
// A section may hand the chrome a Loader as a panel, so the panel can incubate
// asynchronously. A Loader reports its item's implicit size as its own, so a
// panel whose content is wider than the section would push the chrome's layout
// past the screen edge unless the loader's geometry is bound.
//
// The wallet hit this: the center panel is a StackView whose content is wider
// than a phone, and wrapping it in an unbound Loader overflowed to the right.
Item {
id: root
width: 390
height: 700
Component {
id: layoutComponent
StatusSectionLayoutPortrait {
anchors.fill: parent
}
}
// Content deliberately wider than the section, as a StackView holding a
// desktop-width page is.
Component {
id: wideContent
Rectangle { implicitWidth: 5000; implicitHeight: 2000 }
}
// What the wallet did first: no geometry of its own.
Component {
id: unboundLoader
Loader { sourceComponent: wideContent }
}
// What it does now: bound to the chrome for the unparented phase.
Component {
id: boundLoader
Loader {
width: root.width
height: root.height
sourceComponent: wideContent
}
}
// What the wallet's center panel actually is: a StackView that fills its
// parent with side margins, wrapped in a Loader.
Component {
id: walletShapedLoader
Loader {
sourceComponent: Component {
Item {
anchors.fill: parent
anchors.leftMargin: 48
anchors.rightMargin: 48
implicitWidth: 5000
implicitHeight: 2000
}
}
}
}
// Host Item absorbs the loader's sizing; the StackView anchors inside it,
// so the margins resolve against a real parent instead of the loader.
Component {
id: hostedStackLoader
Loader {
sourceComponent: Component {
Item {
StackView {
anchors.fill: parent
anchors.leftMargin: 48
anchors.rightMargin: 48
initialItem: Rectangle { implicitWidth: 5000; implicitHeight: 2000 }
}
}
}
}
}
// Control padding on the stack itself, which does NOT inset the page:
// StackView sizes currentItem to the whole view. Kept as the evidence for
// why the wallet's inset lives on the page (RightTabBaseView) instead.
Component {
id: paddedStackLoader
Loader {
sourceComponent: Component {
StackView {
leftPadding: 48
rightPadding: 48
initialItem: Rectangle { implicitWidth: 5000; implicitHeight: 2000 }
}
}
}
}
TestCase {
name: "SectionPanelLoaderGeometry"
when: windowShown
property var layout: null
function init() {
layout = createTemporaryObject(layoutComponent, root)
verify(!!layout)
}
function test_boundLoaderPanelDoesNotOverflowTheSection() {
layout.centerPanel = createTemporaryObject(boundLoader, root)
waitForRendering(layout)
const panel = layout.centerPanel
verify(panel.width > 0, "panel should have been given a width")
compare(panel.width <= root.width, true,
`center panel is ${panel.width}px wide in a ${root.width}px section`)
}
// The decisive case: is the binding load-bearing at all? ChatView runs
// this same pattern with no geometry on its center panel loader.
function test_unboundLoaderAsPanelDoesNotOverflowEither() {
layout.centerPanel = createTemporaryObject(unboundLoader, root)
waitForRendering(layout)
const panel = layout.centerPanel
console.info("UNBOUND panel width=", panel.width, "implicitWidth=", panel.implicitWidth,
"section width=", root.width)
compare(panel.width <= root.width, true,
`unbound center panel is ${panel.width}px in a ${root.width}px section`)
}
function test_walletShapedPanelDoesNotOverflow() {
layout.centerPanel = createTemporaryObject(walletShapedLoader, root)
waitForRendering(layout)
const panel = layout.centerPanel
const inner = panel.item
console.info("WALLETSHAPE loader w=", panel.width, "x=", panel.x,
"| inner w=", inner ? inner.width : -1, "x=", inner ? inner.x : -1,
"| section w=", root.width)
compare(panel.width <= root.width, true, `loader ${panel.width}px in ${root.width}px`)
verify(!!inner)
compare(inner.width <= root.width, true, `inner ${inner.width}px in ${root.width}px`)
}
function test_hostedStackViewInsetsWithoutOverflowing() {
layout.centerPanel = createTemporaryObject(hostedStackLoader, root)
waitForRendering(layout)
const host = layout.centerPanel.item
const stack = host.children[0]
console.info("HOSTED host w=", host.width, "| stack w=", stack.width, "x=", stack.x,
"| section w=", root.width)
compare(host.width <= root.width, true, `host ${host.width}px in ${root.width}px`)
compare(stack.width, root.width - 96, "stack should be inset by both margins")
compare(stack.x, 48, "stack should start after the left margin")
}
// The stack itself does not overflow - but its padding buys nothing:
// StackView sizes currentItem to the view, padding and all. Anything
// that needs an inset has to carry it on the page.
function test_paddedStackViewIgnoresItsOwnPadding() {
layout.centerPanel = createTemporaryObject(paddedStackLoader, root)
waitForRendering(layout)
const panel = layout.centerPanel
const stack = panel.item
const content = stack.currentItem
console.info("PADDED stack w=", stack.width, "| content w=", content.width,
"x=", content.x, "| section w=", root.width)
compare(stack.width <= root.width, true, `stack ${stack.width}px in ${root.width}px`)
compare(content.width, stack.width,
"StackView sizes currentItem to itself, ignoring its padding")
compare(content.x, 0, "...and positions it at the origin")
}
// Guards the reason the binding exists: without it the loader adopts
// the content's implicit width. If this ever stops overflowing, the
// binding above is no longer load-bearing and the test should be
// revisited rather than deleted.
function test_unboundLoaderAdoptsItsContentWidth() {
const loader = createTemporaryObject(unboundLoader, root)
waitForRendering(loader)
compare(loader.implicitWidth, 5000,
"a Loader reports its item's implicit width as its own")
}
}
}