mirror of
https://github.com/status-im/status-app.git
synced 2026-08-27 15:11:20 +00:00
Alex Jbanca
754276d853
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`.
Building Storybook
For regular usage of Storybook it's enough to open status-desktop/storybook/CMakeLists.txt in QtCreator. Please do not use StoryBook.pro which is intended for WebAssembly builds. Please make sure that selected run target is Storybook.
Storybook may run in two modes (configurable by -m/--mode command line argument):
- local - in this mode local filesystem is observed directly and when change detected the page is unloaded, qml cache is cleaned and page is loaded again
- remote - in this mode the both change detection and qml files access is done via http server. It allows exposing local source code to remote devices
On desktop both modes work basically in the same way from the user perspective.
In order to run Storybook it's necessary to use remote mode:
- connect device
- start Storybook locally in remote mode
- set up reverse proxy (
adb reverse tcp:8080 tcp:8080) - run the Storybook on the device
For convenience the setup of reverse proxy can be easily added to the config
in QtCreator as a deployment step (Custom Process Step).
Building Storybook with Webassembly and Qt 5.14
Warning
Both support for Webassembly and the instruction below are not maintained and won't work out of the box. Please use the standard build/deploy method.
Configuring the environment
Install Emscripten v1.38.27
# Get the emsdk repo
git clone https://github.com/emscripten-core/emsdk.git
#go to emsdk folder
cd emsdk
#install Emscripten v1.38.27
./emsdk install emscripten-1.38.27
#activate emscripten-1.38.27
./emsdk activate emscripten-1.38.27
#install Fastcomp backend
./emsdk install fastcomp-clang-tag-e1.38.27-64bit
#activate Fastcomp backend
./emsdk activate fastcomp-clang-tag-e1.38.27-64bit
#add emsdk tools to env variables
#this can be done by following instructions received from previous activate command
#there are two options:
#1. Configure the env variables for the current shell only:
source emsdk_env.sh
#2. Configure the env variables using the shell startup script:
echo 'source "[path to emsdk folder]/emsdk_env.sh"' >> $HOME/.zprofile
#WARNING: this will configure the environment to use the emsdk compiler
#Ex:"which clang" command will now point to the emscripten clang instead of the system clang
#to disable the env configuration comment the source command added earlier in ~/.zprofile
#check environment
#python needs to be installed. The emsdk scripts state that it should work with pyton 2 and 3
#make sure python command can be resolved
which python
em++ --version
emcc --version
#clang should point to fastcomp-clang-tag-e1.38.27-64bit
which clang
which clang++
More documentation: https://emscripten.org/docs/getting_started/downloads.html
Configure QtCreator (optional)
Newer versions of QtCreator won't support Qt5.14 with Webassembly. Latest version found to support Qt5.14 with WebAssembly is 4.14.2 Download: https://download.qt.io/archive/qtcreator/4.14/
Adding the Emscripten compilers (emcc and em++) Details here: https://doc.qt.io/qtcreator/creator-tool-chains.html
Adding Qt version 5.14: https://doc.qt.io/qtcreator/creator-project-qmake.html
Adding Qt5.14 for Webassembly kit: https://doc.qt.io/qtcreator/creator-targets.html
Open StoryBook.pro in Qt Creator and configure it using the new kit.
Qt creator might not set the env paths correctly. In this case manually set build environment variables (Projects -> 5.14.2 kit -> Build -> Build Environment -> Batch edit). Ex:
EMSCRIPTEN=~/Repos/emsdk/emscripten/1.38.27
EMSDK=~/Repos/emsdk
EMSDK_NODE=~/Repos/emsdk/node/14.18.2_64bit/bin/node
EMSDK_PYTHON=~/Repos/emsdk/python/3.9.2_64bit/bin/python3
EM_CONFIG=~/Repos/emsdk/.emscripten
LLVM_ROOT=~/Repos/emsdk/fastcomp-clang/tag-e1.38.27/build_tag-e1.38.27_64/bin
PATH=[check echo $PATH]
Running qmake (without qt Creator)
#create build folder
mkdir buildStoryBook
#go to folder
cd buildStoryBook
#run qmake (add CONFIG+=debug CONFIG+=qml_debug to qmake command for debug build)
~/Qt/5.14.2/wasm_32/bin/qmake [path to StoryBook.pro] -spec wasm-emscripten && /usr/bin/make qmake_all
#build (add -j[nb of cores] for parallel execution)
make
#run
emrun StoryBook.html