Measured v1.10.0..main (124 commits) on a full-demo export, on Linux, with
screen-recorder-benchmark. The
headline is that the export got ~4.2% faster — and that all of it is one commit.
Filing it because two of the secondary observations look worth a look, not because anything is
broken.
Result
Three builds, measured in a single run so all three are divided by floors from the same session:
| build |
cost x floor |
export (median) |
attributable to |
| release v1.10.0 |
4.099x |
78.16 s |
— |
main @ f22a3a9, wallpaper commit reverted |
4.105x |
78.11 s |
the other 123 commits: +0.14% |
main @ f22a3a9, full |
3.932x |
74.85 s |
f22a3a9 alone: −4.22% |
|
|
|
total: −4.09% |
f22a3a9 is perf(wallpapers): cap the bundled backgrounds at 3840px. CPU seconds move with it
(124 → 118); nothing else does.
The control leg is the point. main with that one commit reverted is indistinguishable from
the release: 78.11 s against 78.16 s, 0.06% apart, with within-leg spreads of 0.50% and 1.12%.
That is not a failure to detect — the wallpaper effect shows up at 8-9x the noise in the same
run, so the method had the resolution to see a comparable effect from anything else if one
existed. On this scenario, the compositor work in that range (texture-cache bounding, webcam
segmentation moved into the shader, the Linux compositor changes) costs and saves nothing
measurable.
Confirmed twice, hours apart: an earlier two-way A/B gave −4.62% (cost) / −4.38% (seconds)
against this run's −4.09% / −4.23%.
Two things worth a look
1. Peak RSS went up, across both steps. The commit's own measurements are about resident
wallpaper memory (1774 MB → 772 MB for all 18). Host RSS during a single-wallpaper export moved
the other way, and reproducibly — three scoring runs per build, spread inside each under 2%:
| build |
peak RSS per run |
mean |
| release v1.10.0 |
970 / 970 / 969 MiB |
970 |
main, wallpaper commit reverted |
987 / 991 / 991 MiB |
990 (+2.1%) |
main, full |
1020 / 1015 / 1032 MiB |
1022 (+5.4% vs release) |
This is not a contradiction of the commit — RSS is not VRAM, and one wallpaper is not eighteen —
but the direction is the opposite of what a reader of that message would expect, and about half
of it appears before the wallpaper commit, so something else in the range is holding more too.
2. The reverted build ships the same wallpapers as the release, and still renders different
bytes. Output is deterministic within each build (three byte-identical exports each), so this
is a real difference and not encoder noise:
| build |
output |
| release v1.10.0 |
15,756,465 B |
main, wallpaper commit reverted |
15,470,905 B |
main, full |
15,448,442 B |
Same input, same wallpaper assets, same 3600 frames at 1920x1080/60 — so something among the
other 123 commits changes the rendered image while costing no time. Probably intended (the
compositor and webcam-segmentation work is in that range); flagging it in case it is not.
Scope, and what this does not say
- One scenario, one machine. Ryzen 5 7520U / Radeon 610M, Ubuntu 24.04, Wayland, VAAPI floor.
- This scenario leans directly on the bundled wallpaper: it sets
background.source: "tool-default", so it composites OpenScreen's own background. A project
with a user-supplied background would likely show close to nothing from f22a3a9. "OpenScreen
got 4% faster" would be too broad a reading.
- It is a quality tradeoff, not free speed. The background is downsampled — 6016x6016 →
3840x3840 for wallpaper10.jpg, a 2.45x cut in source texels. At a 1080p output 3840 px is
still 2x the output width, so it should be invisible; it is still a change to what is rendered.
- Every export here passed verification: 60.000 s, 3600 frames, 1920x1080 @ 60.017, h264,
matching audio loudness, full fidelity, all pixel checks.
Reproducing
node bench.mjs run --bundle commons-upload --apps openscreen-cli
The three-way comparison used two throwaway adapters pointing at locally built binaries, so that
all builds are measured in one run. That matters on this machine specifically: its VAAPI block has
two sustained clocks and cost-in-units-of-the-floor moves ~20% between runs depending which one it
is in, so a before/after taken from two separate runs would be measuring the encoder rather than
the commits. Floors here were 19.07 / 19.03 / 19.04 s across the three legs, with a closing
control at 19.05 s and drift 0.9990x.
Builds were npm run build:linux's steps individually, then electron-builder --linux dir. The
whisper/STT binaries were staged from the release AppImage — unrelated to the export path, and
held identical across all three builds deliberately.
Measured
v1.10.0..main(124 commits) on a full-demo export, on Linux, withscreen-recorder-benchmark. The
headline is that the export got ~4.2% faster — and that all of it is one commit.
Filing it because two of the secondary observations look worth a look, not because anything is
broken.
Result
Three builds, measured in a single run so all three are divided by floors from the same session:
main@ f22a3a9, wallpaper commit revertedmain@ f22a3a9, fullf22a3a9 is
perf(wallpapers): cap the bundled backgrounds at 3840px. CPU seconds move with it(124 → 118); nothing else does.
The control leg is the point.
mainwith that one commit reverted is indistinguishable fromthe release: 78.11 s against 78.16 s, 0.06% apart, with within-leg spreads of 0.50% and 1.12%.
That is not a failure to detect — the wallpaper effect shows up at 8-9x the noise in the same
run, so the method had the resolution to see a comparable effect from anything else if one
existed. On this scenario, the compositor work in that range (texture-cache bounding, webcam
segmentation moved into the shader, the Linux compositor changes) costs and saves nothing
measurable.
Confirmed twice, hours apart: an earlier two-way A/B gave −4.62% (cost) / −4.38% (seconds)
against this run's −4.09% / −4.23%.
Two things worth a look
1. Peak RSS went up, across both steps. The commit's own measurements are about resident
wallpaper memory (1774 MB → 772 MB for all 18). Host RSS during a single-wallpaper export moved
the other way, and reproducibly — three scoring runs per build, spread inside each under 2%:
main, wallpaper commit revertedmain, fullThis is not a contradiction of the commit — RSS is not VRAM, and one wallpaper is not eighteen —
but the direction is the opposite of what a reader of that message would expect, and about half
of it appears before the wallpaper commit, so something else in the range is holding more too.
2. The reverted build ships the same wallpapers as the release, and still renders different
bytes. Output is deterministic within each build (three byte-identical exports each), so this
is a real difference and not encoder noise:
main, wallpaper commit revertedmain, fullSame input, same wallpaper assets, same 3600 frames at 1920x1080/60 — so something among the
other 123 commits changes the rendered image while costing no time. Probably intended (the
compositor and webcam-segmentation work is in that range); flagging it in case it is not.
Scope, and what this does not say
background.source: "tool-default", so it composites OpenScreen's own background. A projectwith a user-supplied background would likely show close to nothing from f22a3a9. "OpenScreen
got 4% faster" would be too broad a reading.
3840x3840 for
wallpaper10.jpg, a 2.45x cut in source texels. At a 1080p output 3840 px isstill 2x the output width, so it should be invisible; it is still a change to what is rendered.
matching audio loudness, full fidelity, all pixel checks.
Reproducing
The three-way comparison used two throwaway adapters pointing at locally built binaries, so that
all builds are measured in one run. That matters on this machine specifically: its VAAPI block has
two sustained clocks and cost-in-units-of-the-floor moves ~20% between runs depending which one it
is in, so a before/after taken from two separate runs would be measuring the encoder rather than
the commits. Floors here were 19.07 / 19.03 / 19.04 s across the three legs, with a closing
control at 19.05 s and drift 0.9990x.
Builds were
npm run build:linux's steps individually, thenelectron-builder --linux dir. Thewhisper/STT binaries were staged from the release AppImage — unrelated to the export path, and
held identical across all three builds deliberately.