Skip to content

Skirmish: a full-stack real-time card battler sample - #6074

Merged
shai-almog merged 33 commits into
masterfrom
skirmish-game-sample
Oct 22, 2026
Merged

Skirmish: a full-stack real-time card battler sample#6074
shai-almog merged 33 commits into
masterfrom
skirmish-game-sample

Conversation

@shai-almog

@shai-almog shai-almog commented Oct 22, 2026

Copy link
Copy Markdown
Collaborator

Adds Skirmish, a third full-stack sample next to Wayline and Savor, this time a game: a Clash Royale-style real-time card battler with a Codename One client and a Codename One Backend in scripts/skirmish.

What's in it

  • rules: a deterministic simulation with no floating point, no clock and its own seeded RNG. The app, the server, replays and the tests all compile it. Golden replays and determinism tests are included.
  • backend:
    • accounts, decks, matchmaking and challenge links;
    • server-authoritative lockstep match rooms over WebSocket, replays and spectating;
    • levels, quests, chests and achievements;
    • store receipt validation and push;
    • moderation (flags, audited actions).
  • common:
    • a 3D battle drawn with com.codename1.gaming, using glTF KayKit models (CC0, NOTICE entry) and particles, with a finishing camera sweep;
    • a guided training battle, and CSS-styled game menus;
    • the shop, rewarded and interstitial ads, analytics, and the admin console.
  • ios: the native iOS build (ios-source).
  • Docs:
    • user's and implementor's chapters in the developer guide;
    • the /skirmish/ website page and flagship card;
    • a README.
  • Initializr: a new card-battler template.
  • CI: .github/workflows/skirmish.yml covers template parity, rules, the backend on the JVM and on real databases, client E2E, and Android and iOS builds.

Framework changes

  • IOSNative.m SoundPool fixes:

    • nativeLoadSound's POOL_BEGIN shadowed the pool parameter and crashed on load.
    • A main-thread dispatch_sync from the GPU frame callback deadlocked. It now runs the block inline when already on the main thread.

  • MCP-Headless-API.asciidoc gets an explicit anchor so other chapters can link it.

  • validate-guide-snippets.py accepts CSS snippets from the sample's own compiled theme.

  • sync-initializr-template.py gains:

    • an optional rules module;
    • the rename applied to the settings hints;
    • .txt handled as text.

    Savor and Wayline parity still pass.

🤖 Generated with Claude Code

shai-almog and others added 12 commits October 21, 2026 15:01
@shai-almog @claude
Skirmish sample: deterministic shared rules module
b14511a 
A Clash Royale-style card battler sample. This first piece is the rules
module the app, the server and the replay viewer will all run: fixed
20 Hz ticks, integer-only arithmetic, a seeded SplitMix64 RNG, a data
driven card catalog, a practice bot, and replays as seed + decks +
command log. Tests pin determinism with a golden replay corpus that the
cross-platform check will replay on ParparVM and the JS port.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog @claude
Skirmish sample: authoritative game backend
d299b62 
Accounts, decks, trophy matchmaking with a bot fallback, challenge links,
a lockstep match loop over /ws/game that runs the shared rules, replays,
a coin/gem shop with server-side store receipt validation and capped
rewarded ads, player reports and automatic flags, and audited admin
moderation. Flyway migrations for SQLite, PostgreSQL and MySQL.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog @claude
Skirmish sample: game client, engagement, admin console
96f6aa8 
The Codename One client: a com.codename1.gaming arena with CSS-styled
widgets around it (hand, elixir meter, name banner), practice against
the bot, online lockstep, challenge links, replays, deck builder, shop
with server-validated purchases, rewarded/interstitial/banner ads,
analytics, push, and the admin god-mode console. Simulator E2E tests
capture the developer-guide screenshots. Hash hex moves into the rules
module because Long.toHexString does not exist on device.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog @claude
gpu: glTF scenes with skins and animation, AnimatedModel and Particle…
3e67a47 
…Emitter

GltfLoader.loadScene reads every node, primitive, material, skin and clip;
AnimatedModel CPU-skins and cross-fades clips through dirty vertex buffers so
no backend changes; ParticleEmitter draws camera-facing additive or alpha
billboards in one call.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog @claude
Skirmish: 3D battle with KayKit characters, towers and particle effects
dc91140 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog @claude
Skirmish: levels, daily quests, chests and achievements on the server
f353361 
Progression keeps experience, chest slots, lifetime counters and three
daily quests per player in a new progress table (portable V4). A
finished match feeds it from Results; quests, chests and the training
battle pay out through /api/progress. Flags.auto opens its own
transaction so the demo seeding's flag is actually stored.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog @claude
Skirmish: tutorial, card and hero art, home progression and reward po…
50f0dee 
…pups

- A training battle walks a new player through elixir, deploying,
  defending and spells: a mentor in a speech bubble, time held still
  while she talks, and an animated finger on the card to pick and the
  spot to drag it to. It starts on a new player's first visit and is
  replayable from "How to play".
- Cards are framed renders of the battle's own 3D models (CardArt),
  with an elixir drop and a name ribbon, in the hand, the deck and the
  home strip; heroes in their victory pose on sign-in, home, results
  and reward popups. PortraitStudio also renders the Imp Den.
- Home shows the hero, level and XP bar, chest slots, daily quests
  with a claim button, and a trophy room of achievements; rewards,
  level-ups and unlocks pop up with the hero.
- Fields and buttons share one centred column width, so sign-in and
  register line up.
- Demo accounts are seeded with some progress; the dead 2D sprite
  code in Art and Viewport is gone.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog @claude
Skirmish: finishing camera sweep, game-styled dialogs, reward popup a…
70f7a54 
…nd back arrow fixes

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog @claude
Skirmish: native iOS build and a self-driving walkthrough; fix two iO…
acdd4aa 
…S SoundPool crashes

The iOS sound pool's load shadowed its pool argument with POOL_BEGIN's
autorelease pool, and play dispatch_sync'ed to the main queue from the GPU
view's frame callback, which already runs there.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog @claude
Skirmish: developer-guide chapters, demo page, Initializr template an…
921fc18 
…d CI

Adds the user's and implementor's guides, the /skirmish/ website page and
flagship card, the README, the Initializr template and the skirmish workflow.
Challenge links open the installed app through its skirmish: URL scheme
unless a hosted browser build is configured.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog @claude
Skirmish: review round 2 - guide facts, portrait path, workflow paths
330c915 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog
Merge remote-tracking branch 'origin/master' into skirmish-game-sample
7c951bd 
# Conflicts:
#	NOTICE
@github-actions

github-actions Bot commented Oct 22, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Developer Guide build artifacts are available for download from this workflow run:

Developer Guide quality checks:

  • AsciiDoc linter: No issues found (report)
  • Vale: No alerts found (report)
  • Paragraph capitalization: No paragraph capitalization issues (report)
  • LanguageTool: No grammar matches (report)
  • Image references: No unused images detected (report)

@shai-almog @claude
CI: build a sample's rules module in the database server tests
d887e94 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog

shai-almog commented Oct 22, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Compared 214 screenshots: 214 matched.
✅ JavaScript-port screenshot tests passed.

@shai-almog

shai-almog commented Oct 22, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Compared 193 screenshots: 193 matched.
Native Windows port (x64 / Intel-AMD): full hellocodenameone screenshot suite rendered offscreen with Direct2D/DirectWrite, plus the real benchmarks (base64 native/CN1/SIMD, image createMask/applyMask/modifyAlpha/PNG/JPEG, SSE2 SIMD kernels). Compared against the in-repo baseline in scripts/windows/screenshots.

Benchmark Results

Detailed Performance Metrics

Metric Duration
SIMD kernel backend SSE2 (x64) / NEON (arm64) native kernels
SIMD int-add (64K x300) java 57ms / native 5ms = 11.4x speedup
SIMD float-mul (64K x300) java 62ms / native 4ms = 15.5x speedup
SIMD kernel correctness PASS (native result == scalar reference)
Base64 native bridge unavailable (CN1 + SIMD + image benchmarks only)
Base64 payload size 8192 bytes
Base64 benchmark iterations 6000
Base64 SIMD byte path gated to scalar (CPU autovectorizes scalar; explicit SIMD not beneficial here)
Base64 CN1 encode 92.000 ms
Base64 CN1 decode 118.000 ms
Base64 SIMD encode 139.000 ms
Base64 encode ratio (SIMD/CN1) 1.511x (51.1% slower)
Base64 SIMD decode 126.000 ms
Base64 decode ratio (SIMD/CN1) 1.068x (6.8% slower)
Image encode benchmark iterations 100
Image createMask (SIMD off) 14.000 ms
Image createMask (SIMD on) 8.000 ms
Image createMask ratio (SIMD on/off) 0.571x (42.9% faster)
Image applyMask (SIMD off) 57.000 ms
Image applyMask (SIMD on) 68.000 ms
Image applyMask ratio (SIMD on/off) 1.193x (19.3% slower)
Image modifyAlpha (SIMD off) 37.000 ms
Image modifyAlpha (SIMD on) 32.000 ms
Image modifyAlpha ratio (SIMD on/off) 0.865x (13.5% faster)
Image modifyAlpha removeColor (SIMD off) 50.000 ms
Image modifyAlpha removeColor (SIMD on) 28.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off) 0.560x (44.0% faster)

ParparVM vs HotSpot (JDK 25): Windows x64

Runner CPU: AMD64 Family 25 Model 1 Stepping 1, AuthenticAMD (baseline windows-x64@amd64-family-25-model-1-authenticamd)

Ratios are ParparVM / JDK 25: below 1.00x ParparVM is faster (time) or smaller (RAM). Median of 5 interleaved, paired rounds; every run's output was verified. A ratio more than 20% (time) / 25% (RAM) above its baseline in vm/selfhost/perf-baseline/ is a regression and fails; one that far below is an improvement, reported but not failed (a row whose calibration runs were noisier carries a wider tolerance), and for RAM the change must also exceed 0.05x in absolute terms. Both run unpinned on all of the runner's CPUs, with their own default thread counts.

Benchmark Cores Time RAM Status
hello (WinHelloMain) 4 1.46x (base 1.22x, +19.5%) 0.56x (base 0.94x, -40.4%) ok
translator (self) 4 0.79x (base 0.60x, +30.9%) 0.53x (base 0.54x, -2.3%) ok
intArithmetic 4 1.10x (base 1.10x, +0.0%) 0.06x (base 0.06x, +1.5%) ok
longArithmetic 4 1.14x (base 1.08x, +5.1%) 0.06x (base 0.05x, +2.5%) ok
mathTranscendental 4 0.78x (base 0.79x, -0.9%) 0.06x (base 0.06x, +1.8%) ok
arraySequential 4 1.42x (base 1.36x, +4.4%) 0.39x (base 0.39x, +0.5%) ok
arrayRandom 4 0.98x (base 1.06x, -7.5%) 0.23x (base 0.23x, +0.4%) ok
objectAllocation 4 1.59x (base 1.56x, +1.8%) 0.29x (base 0.39x, -24.4%) ok
valueEscape 4 0.10x (base 0.10x, +0.4%) 0.05x (base 0.04x, +4.1%) ok
hashMapChurn 4 1.89x (base 1.80x, +4.9%) 0.09x (base 0.09x, -1.6%) ok
stringBuilding 4 1.22x (base 1.22x, +0.6%) 0.32x (base 0.32x, +0.1%) ok
recursion 4 1.41x (base 1.49x, -5.8%) 0.06x (base 0.06x, +0.5%) ok
quicksort 4 1.11x (base 1.13x, -2.2%) 0.12x (base 0.12x, +0.5%) ok

Result: no regression

@github-actions

github-actions Bot commented Oct 22, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

✅ Continuous Quality Report

Test & Coverage

Static Analysis

  • SpotBugs [Report archive]
    • ✅ ByteCodeTranslator: 0 findings (no issues)
    • ✅ android: 0 findings (no issues)
    • ✅ android-compat: 0 findings (no issues)
    • ✅ android-res-compiler: 0 findings (no issues)
    • ✅ backend: 0 findings (no issues)
    • ✅ backend-test: 0 findings (no issues)
    • ✅ build-engine: 0 findings (no issues)
    • ✅ build-hint-catalog: 0 findings (no issues)
    • ✅ build-hint-tools: 0 findings (no issues)
    • ✅ codenameone-gradle-plugin: 0 findings (no issues)
    • ✅ codenameone-maven-plugin: 0 findings (no issues)
    • ✅ core-unittests: 0 findings (no issues)
    • ✅ ios: 0 findings (no issues)
    • ✅ javac: 0 findings (no issues)
    • ✅ project-model: 0 findings (no issues)
  • ❌ PMD: 1 findings (P3: 1) [HTML preview] [Download]
  • ✅ Checkstyle: 0 findings (no issues) [Report archive]

Generated automatically by the PR CI workflow.

@shai-almog

shai-almog commented Oct 22, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Compared 193 screenshots: 193 matched.
Native Windows port (arm64 / Apple Silicon - Arm): full hellocodenameone screenshot suite rendered offscreen with Direct2D/DirectWrite, plus the real benchmarks (base64 native/CN1/SIMD, image createMask/applyMask/modifyAlpha/PNG/JPEG, NEON SIMD kernels). Compared against the in-repo baseline in scripts/windows/screenshots.

Benchmark Results

Detailed Performance Metrics

Metric Duration
SIMD kernel backend SSE2 (x64) / NEON (arm64) native kernels
SIMD int-add (64K x300) java 53ms / native 2ms = 26.5x speedup
SIMD float-mul (64K x300) java 53ms / native 2ms = 26.5x speedup
SIMD kernel correctness PASS (native result == scalar reference)
Base64 native bridge unavailable (CN1 + SIMD + image benchmarks only)
Base64 payload size 8192 bytes
Base64 benchmark iterations 6000
Base64 SIMD byte path gated to scalar (CPU autovectorizes scalar; explicit SIMD not beneficial here)
Base64 CN1 encode 61.000 ms
Base64 CN1 decode 69.000 ms
Base64 SIMD encode 78.000 ms
Base64 encode ratio (SIMD/CN1) 1.279x (27.9% slower)
Base64 SIMD decode 69.000 ms
Base64 decode ratio (SIMD/CN1) 1.000x (0.0% slower)
Image encode benchmark iterations 100
Image createMask (SIMD off) 4.000 ms
Image createMask (SIMD on) 1.000 ms
Image createMask ratio (SIMD on/off) 0.250x (75.0% faster)
Image applyMask (SIMD off) 21.000 ms
Image applyMask (SIMD on) 21.000 ms
Image applyMask ratio (SIMD on/off) 1.000x (0.0% slower)
Image modifyAlpha (SIMD off) 18.000 ms
Image modifyAlpha (SIMD on) 10.000 ms
Image modifyAlpha ratio (SIMD on/off) 0.556x (44.4% faster)
Image modifyAlpha removeColor (SIMD off) 18.000 ms
Image modifyAlpha removeColor (SIMD on) 12.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off) 0.667x (33.3% faster)

ParparVM vs HotSpot (JDK 25): Windows arm64

Runner CPU: ARMv8 (64-bit) Family 8 Model D49 Revision 0, MICROSOFT CORPORATION (baseline windows-arm64@armv8-64-bit-family-8-model-d49-microsoft-corporation)

Ratios are ParparVM / JDK 25: below 1.00x ParparVM is faster (time) or smaller (RAM). Median of 5 interleaved, paired rounds; every run's output was verified. A ratio more than 20% (time) / 25% (RAM) above its baseline in vm/selfhost/perf-baseline/ is a regression and fails; one that far below is an improvement, reported but not failed (a row whose calibration runs were noisier carries a wider tolerance), and for RAM the change must also exceed 0.05x in absolute terms. Both run unpinned on all of the runner's CPUs, with their own default thread counts.

Benchmark Cores Time RAM Status
hello (WinHelloMain) 4 1.02x (base 1.11x, -8.1%) 0.77x (base 0.75x, +2.2%) ok
translator (self) 4 0.84x (base 0.84x, +0.2%) 0.46x (base 0.51x, -8.7%) ok
intArithmetic 4 1.04x (base 1.04x, +0.1%) 0.06x (base 0.06x, +2.6%) ok
longArithmetic 4 0.79x (base 0.80x, -0.0%) 0.06x (base 0.06x, +3.2%) ok
mathTranscendental 4 0.72x (base 0.72x, -0.4%) 0.06x (base 0.06x, +1.4%) ok
arraySequential 4 0.39x (base 0.46x, -13.3%) 0.39x (base 0.39x, +0.2%) ok
arrayRandom 4 0.93x (base 0.94x, -0.4%) 0.23x (base 0.23x, +0.3%) ok
objectAllocation 4 1.75x (base 2.81x, -37.7%) 0.41x (base 0.43x, -3.5%) ok
valueEscape 4 0.76x (base 0.76x, +0.0%) 0.05x (base 0.05x, +2.9%) ok
hashMapChurn 4 0.99x (base 0.98x, +1.0%) 0.12x (base 0.12x, -1.5%) ok
stringBuilding 4 1.60x (base 1.43x, +12.3%) 0.27x (base 0.27x, -0.4%) ok
recursion 4 1.55x (base 1.46x, +5.8%) 0.07x (base 0.07x, +0.8%) ok
quicksort 4 1.00x (base 1.00x, +0.3%) 0.12x (base 0.12x, +0.6%) ok

Result: no regression

@shai-almog @claude
Skirmish CI: PMD, doc snippets, LanguageTool, Android licence key, si…
c1c5269 
…lent sim audio

- Core gaming classes: foreach loops and documented NOPMD on the intentional
  identity checks and the per-frame scratch matrix; AnimatedModel and
  ParticleEmitter javadoc examples are complete runnable programs.
- Guide: Playground opt-out for sample code, the MCP link uses the chapter's
  generated id again (the explicit anchor broke the website's links),
  LanguageTool terms.
- Skirmish: placeholder android.licenseKey for its in-app purchases; Sfx only
  uses a native mixer, so a simulator without an audio device stays silent
  instead of starting a browser engine per sound.
- From #6059: perf-baseline overlay 5976 re-measured, starter-launchers macOS
  timeout.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@github-actions

github-actions Bot commented Oct 22, 2026

Copy link
Copy Markdown
Contributor

Cloudflare Preview

@shai-almog

shai-almog commented Oct 22, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Compared 178 screenshots: 178 matched.

Native Android coverage

  • 📊 Line coverage: 17.40% (30692/176354 lines covered) [HTML preview] (artifact android-coverage-report, jacocoAndroidReport/html/index.html)
    • Other counters: instruction 15.71% (144995/923169), branch 10.67% (10017/93896), complexity 8.23% (7453/90604), method 12.02% (5159/42930), class 20.76% (1060/5105)
    • Lowest covered classes
      • kotlin.collections.kotlin.collections.ArraysKt___ArraysKt – 0.00% (0/6367 lines covered)
      • kotlin.collections.unsigned.kotlin.collections.unsigned.UArraysKt___UArraysKt – 0.00% (0/2384 lines covered)
      • org.jacoco.agent.rt.internal_0e20598.asm.org.jacoco.agent.rt.internal_0e20598.asm.ClassReader – 0.00% (0/1524 lines covered)
      • org.jacoco.agent.rt.internal_0e20598.asm.org.jacoco.agent.rt.internal_0e20598.asm.MethodWriter – 0.00% (0/922 lines covered)
      • kotlin.sequences.kotlin.sequences.SequencesKt___SequencesKt – 0.00% (0/736 lines covered)
      • com.google.common.cache.com.google.common.cache.LocalCache$Segment – 0.00% (0/726 lines covered)
      • okio.okio.Buffer – 0.00% (0/687 lines covered)
      • kotlin.text.kotlin.text.StringsKt___StringsKt – 0.00% (0/625 lines covered)
      • com.codename1.androidcompat.rt.com.codename1.androidcompat.rt.TextXmlPullParser – 0.00% (0/623 lines covered)
      • com.codename1.androidcompat.androidx.constraintlayout.core.widgets.com.codename1.androidcompat.androidx.constraintlayout.core.widgets.Flow – 0.00% (0/576 lines covered)

✅ Native Android screenshot tests passed.

Native Android coverage

  • 📊 Line coverage: 17.40% (30692/176354 lines covered) [HTML preview] (artifact android-coverage-report, jacocoAndroidReport/html/index.html)
    • Other counters: instruction 15.71% (144995/923169), branch 10.67% (10017/93896), complexity 8.23% (7453/90604), method 12.02% (5159/42930), class 20.76% (1060/5105)
    • Lowest covered classes
      • kotlin.collections.kotlin.collections.ArraysKt___ArraysKt – 0.00% (0/6367 lines covered)
      • kotlin.collections.unsigned.kotlin.collections.unsigned.UArraysKt___UArraysKt – 0.00% (0/2384 lines covered)
      • org.jacoco.agent.rt.internal_0e20598.asm.org.jacoco.agent.rt.internal_0e20598.asm.ClassReader – 0.00% (0/1524 lines covered)
      • org.jacoco.agent.rt.internal_0e20598.asm.org.jacoco.agent.rt.internal_0e20598.asm.MethodWriter – 0.00% (0/922 lines covered)
      • kotlin.sequences.kotlin.sequences.SequencesKt___SequencesKt – 0.00% (0/736 lines covered)
      • com.google.common.cache.com.google.common.cache.LocalCache$Segment – 0.00% (0/726 lines covered)
      • okio.okio.Buffer – 0.00% (0/687 lines covered)
      • kotlin.text.kotlin.text.StringsKt___StringsKt – 0.00% (0/625 lines covered)
      • com.codename1.androidcompat.rt.com.codename1.androidcompat.rt.TextXmlPullParser – 0.00% (0/623 lines covered)
      • com.codename1.androidcompat.androidx.constraintlayout.core.widgets.com.codename1.androidcompat.androidx.constraintlayout.core.widgets.Flow – 0.00% (0/576 lines covered)

Benchmark Results

Detailed Performance Metrics

Metric Duration
SIMD kernel backend scalar fallback (no native SIMD)
SIMD int-add (64K x300) java 198ms / native 181ms = 1.0x speedup
SIMD float-mul (64K x300) java 150ms / native 143ms = 1.0x speedup
SIMD kernel correctness PASS (native result == scalar reference)
Base64 payload size 8192 bytes
Base64 benchmark iterations 6000
Base64 SIMD byte path gated to scalar (CPU autovectorizes scalar; explicit SIMD not beneficial here)
Base64 CN1 encode 75.000 ms
Base64 CN1 decode 84.000 ms
Base64 native encode 442.000 ms
Base64 encode ratio (CN1/native) 0.170x (83.0% faster)
Base64 native decode 276.000 ms
Base64 decode ratio (CN1/native) 0.304x (69.6% faster)
Image encode benchmark status skipped (SIMD unsupported)

shai-almog and others added 3 commits October 22, 2026 07:06
@shai-almog @claude
Skirmish CI: GltfScene indentation, flutter-bench baseline from #6059
4ccb7f6 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog @claude
Skirmish Forge: content packs, custom arenas and missions in the rule…
beeb075 
…s, server packs, files and verified mission results

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog @claude
Skirmish Forge: the in-app editor, mission play, moderation and the g…
a9b8f60 
…uide

- Forge home (official, popular, new, yours), pack screen with campaigns,
  stars, share, remix, rate and report; deep links open a pack.
- Editors for packs, cards (stats, bundled looks or an imported .glb with
  its clips mapped on a turntable), arenas (towers and obstacles on a grid,
  mirrored, any size and lane count), missions (goal, elixir, decks, waves,
  story lines, stars, rewards, test play) and campaigns.
- Missions play through BattleForm with a MissionDriver: story lines stop
  the clock, results go to the server, which plays them again.
- Battle view draws any arena, custom cards and uploaded models.
- Admin console Forge tab: reported packs, hide/restore/official, and the
  uploaded files to look at, approve or reject.
- Theme styles for the Forge, an e2e test that captures its screens, guide
  sections for players and implementors, template resync.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@github-actions

github-actions Bot commented Oct 22, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Flutter vs Codename One

Same application, built both ways: Flutter's AOT compile of the gallery, and the identical Dart source transpiled to Java on Codename One. Lower is better for every metric, so a ratio above 1.00x means Codename One is ahead by that factor.

android

9 interleaved rounds; host load 0.46, 1.64, 1.31

Metric Codename One Flutter Ratio Winner
Installed size 78.2 MB 95.8 MB 1.23x Codename One
Executable code 4.6 MB 20.6 MB 4.43x Codename One
Download size (zipped) 78.2 MB 95.8 MB 1.23x Codename One
Cold start to first frame on screen 316 ms 1165 ms 3.42x Codename One
Memory at rest 45.7 MB 79.0 MB 1.72x Codename One

Start-up and memory at rest are judged round by round: the ratio is the median of the per-round ratios, each from two launches made back to back, and the times and sizes shown are each side's median, so the ratio need not equal their quotient. Codename One was ahead in 9 of 9 rounds on cold start to first frame on screen; 9 of 9 rounds on memory at rest.

Compute -- the VM workloads (vm/benchmarks), run inside each app; time is the best of the app's own repetitions, higher ratio means Codename One is faster.

Workload Codename One Flutter Ratio
intArithmetic 55 ms 119 ms 2.16x
longArithmetic 34 ms 34 ms 1.00x
mathTranscendental 157 ms 194 ms 1.24x
arraySequential 17 ms 20 ms 1.18x
arrayRandom 175 ms 209 ms 1.19x
objectAllocation 55 ms 22 ms 0.40x
valueEscape 7 ms 5 ms 0.71x
hashMapChurn 108 ms 209 ms 1.94x
stringBuilding 57 ms 76 ms 1.33x
recursion 41 ms 168 ms 4.10x
quicksortBench 111 ms 121 ms 1.09x
Geometric mean 1.26x

Gate: within tolerance against scripts/flutter-bench/baseline.

Android sizes are for the arm64-v8a slice a phone is delivered, on both sides; Flutter's release apk carries three ABIs and would otherwise count its engine about three times.
Android start-up and memory come from an x86_64 emulator with a software GPU. They compare the two runtimes on one machine; they are not phone timings, and a renderer that leans on the GPU is penalised more there.
This platform's adapter has not been exercised end to end before; treat the first published run as the thing under review.

ios

9 interleaved rounds; host load 29.95, 36.13, 29.61

Metric Codename One Flutter Ratio Winner
Installed size 107.8 MB 110.5 MB 1.02x Codename One
Executable code 16.8 MB 19.1 MB 1.14x Codename One
Download size (zipped) 79.9 MB 81.9 MB 1.02x Codename One
Cold start to first frame on screen -- -- -- not measured
Memory at rest -- -- -- not measured

Compute -- the VM workloads (vm/benchmarks), run inside each app; time is the best of the app's own repetitions, higher ratio means Codename One is faster.

Not measured: iOS compute is not measured: a device build needs signed hardware, and on the simulator Flutter runs its JIT debug engine rather than AOT code. The macOS row runs the same ParparVM and Dart AOT compilers on the same Apple silicon.

Gate: within tolerance against scripts/flutter-bench/baseline. Smaller than its baseline, which does not fail the gate: Executable code -9.20%; Installed size -1.55%; Download size (zipped) -0.76% -- rebaseline to tighten. To accept the move, download this platform's baseline-<platform>.json artifact and run python3 scripts/flutter-bench/flutter_baseline.py calibrate --pr 6074 --reason "<why these moved>" baseline-ios.json, then commit the overlay it writes.

iOS start-up and memory are not measured here: Flutter cannot AOT-compile for the simulator, so a simulator run would time a JIT debug build against a release build. Sizes come from release device bundles; timings need signed hardware.
This platform's adapter has not been exercised end to end before; treat the first published run as the thing under review.

javascript

9 interleaved rounds; host load 2.33, 1.68, 0.77

Metric Codename One Flutter Ratio Winner
Installed size 103.9 MB 122.5 MB 1.18x Codename One
Executable code 12.8 MB 25.2 MB 1.97x Codename One
Download size (zipped) 76.3 MB 84.1 MB 1.10x Codename One
Cold start to first frame on screen -- -- -- not measured
Memory at rest -- -- -- not measured

Compute -- the VM workloads (vm/benchmarks), run inside each app; time is the best of the app's own repetitions, higher ratio means Codename One is faster.

Workload Codename One Flutter Ratio
intArithmetic 646 ms wrong result Flutter: wrong result
longArithmetic 5091 ms did not run Flutter: did not run
mathTranscendental 563 ms did not run Flutter: did not run
arraySequential 228 ms 82 ms 0.36x
arrayRandom 1030 ms wrong result Flutter: wrong result
objectAllocation 38 ms 27 ms 0.71x
valueEscape 110 ms 7 ms 0.06x
hashMapChurn 1090 ms 245 ms 0.23x
stringBuilding 531 ms 107 ms 0.20x
recursion 508 ms 492 ms 0.97x
quicksortBench 435 ms wrong result Flutter: wrong result
Geometric mean 0.30x

Gate: within tolerance against scripts/flutter-bench/baseline; BEHIND FLUTTER on Compute (geomean of the VM workloads) (reported, not gated: a loss to Flutter on the web is currently accepted).

the JavaScript adapter needs a Chrome DevTools driver; sizes are reported and timings are not
This platform's adapter has not been exercised end to end before; treat the first published run as the thing under review.

linux

9 interleaved rounds; host load 0.47, 2.82, 2.37

Metric Codename One Flutter Ratio Winner
Installed size 111.1 MB 143.8 MB 1.29x Codename One
Executable code 13.9 MB 16.1 MB 1.16x Codename One
Download size (zipped) 80.8 MB 92.9 MB 1.15x Codename One
Cold start to first frame on screen 154 ms 220 ms 1.43x Codename One
Memory at rest 85.2 MB 225.4 MB 2.67x Codename One

Start-up and memory at rest are judged round by round: the ratio is the median of the per-round ratios, each from two launches made back to back, and the times and sizes shown are each side's median, so the ratio need not equal their quotient. Codename One was ahead in 9 of 9 rounds on cold start to first frame on screen; 9 of 9 rounds on memory at rest.

Compute -- the VM workloads (vm/benchmarks), run inside each app; time is the best of the app's own repetitions, higher ratio means Codename One is faster.

Workload Codename One Flutter Ratio
intArithmetic 74 ms 183 ms 2.47x
longArithmetic 56 ms 55 ms 0.98x
mathTranscendental 254 ms 276 ms 1.09x
arraySequential 15 ms 35 ms 2.33x
arrayRandom 227 ms 257 ms 1.13x
objectAllocation 24 ms 39 ms 1.62x
valueEscape 5 ms 7 ms 1.40x
hashMapChurn 49 ms 336 ms 6.86x
stringBuilding 33 ms 110 ms 3.33x
recursion 96 ms 258 ms 2.69x
quicksortBench 140 ms 149 ms 1.06x
Geometric mean 1.88x

Gate: OUTSIDE THE BASELINE against scripts/flutter-bench/baseline. Smaller than its baseline, which does not fail the gate: Download size (zipped) -0.01% -- rebaseline to tighten. To accept the move, download this platform's baseline-<platform>.json artifact and run python3 scripts/flutter-bench/flutter_baseline.py calibrate --pr 6074 --reason "<why these moved>" baseline-linux.json, then commit the overlay it writes.

This platform's adapter has not been exercised end to end before; treat the first published run as the thing under review.

windows

9 interleaved rounds

Metric Codename One Flutter Ratio Winner
Installed size 107.5 MB 121.1 MB 1.13x Codename One
Executable code 11.2 MB 14.1 MB 1.26x Codename One
Download size (zipped) 77.7 MB 86.4 MB 1.11x Codename One
Cold start to first frame on screen 156 ms 258 ms 1.62x Codename One
Memory at rest 58.1 MB 92.1 MB 1.58x Codename One

Start-up and memory at rest are judged round by round: the ratio is the median of the per-round ratios, each from two launches made back to back, and the times and sizes shown are each side's median, so the ratio need not equal their quotient. Codename One was ahead in 9 of 9 rounds on cold start to first frame on screen; 9 of 9 rounds on memory at rest.

Compute -- the VM workloads (vm/benchmarks), run inside each app; time is the best of the app's own repetitions, higher ratio means Codename One is faster.

Workload Codename One Flutter Ratio
intArithmetic 80 ms 189 ms 2.36x
longArithmetic 63 ms 64 ms 1.02x
mathTranscendental 198 ms 267 ms 1.35x
arraySequential 11 ms 35 ms 3.18x
arrayRandom 275 ms 312 ms 1.14x
objectAllocation 25 ms 40 ms 1.60x
valueEscape 1 ms 7 ms 7.00x
hashMapChurn 51 ms 322 ms 6.31x
stringBuilding 36 ms 120 ms 3.33x
recursion 193 ms 263 ms 1.36x
quicksortBench 138 ms 146 ms 1.06x
Geometric mean 2.12x

Gate: within tolerance against scripts/flutter-bench/baseline. Smaller than its baseline, which does not fail the gate: Executable code -11.90%; Installed size -1.43%; Download size (zipped) -0.92% -- rebaseline to tighten. To accept the move, download this platform's baseline-<platform>.json artifact and run python3 scripts/flutter-bench/flutter_baseline.py calibrate --pr 6074 --reason "<why these moved>" baseline-windows.json, then commit the overlay it writes.

This platform's adapter has not been exercised end to end before; treat the first published run as the thing under review.

Codename One wins 21 of 21 measured metrics across 5 platform(s).

@shai-almog @claude
Skirmish Forge: only APIs the device and compiled server have
69ad91a 
- ContentPack's hash uses Match.hex, not Long.toHexString, which the device
  runtime lacks (bytecode compliance, Android and template builds).
- Forge splits the stored animation list with Lists.split; String.split is
  not in the compiled backend's runtime.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog

shai-almog commented Oct 22, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Compared 193 screenshots: 193 matched.
Native Windows port, REAL shipping pipeline: the hellocodenameone screenshot suite rendered by a binary CROSS-COMPILED on Linux (clang-cl + xwin, WebView2 linked) and RUN on a Windows x64 runner. Compared against the in-repo baseline in scripts/windows/screenshots.

Benchmark Results

Detailed Performance Metrics

Metric Duration
SIMD kernel backend SSE2 (x64) / NEON (arm64) native kernels
SIMD int-add (64K x300) java 56ms / native 3ms = 18.6x speedup
SIMD float-mul (64K x300) java 56ms / native 3ms = 18.6x speedup
SIMD kernel correctness PASS (native result == scalar reference)
Base64 native bridge unavailable (CN1 + SIMD + image benchmarks only)
Base64 payload size 8192 bytes
Base64 benchmark iterations 6000
Base64 SIMD byte path gated to scalar (CPU autovectorizes scalar; explicit SIMD not beneficial here)
Base64 CN1 encode 77.000 ms
Base64 CN1 decode 94.000 ms
Base64 SIMD encode 118.000 ms
Base64 encode ratio (SIMD/CN1) 1.532x (53.2% slower)
Base64 SIMD decode 100.000 ms
Base64 decode ratio (SIMD/CN1) 1.064x (6.4% slower)
Image encode benchmark iterations 100
Image createMask (SIMD off) 8.000 ms
Image createMask (SIMD on) 4.000 ms
Image createMask ratio (SIMD on/off) 0.500x (50.0% faster)
Image applyMask (SIMD off) 28.000 ms
Image applyMask (SIMD on) 28.000 ms
Image applyMask ratio (SIMD on/off) 1.000x (0.0% slower)
Image modifyAlpha (SIMD off) 31.000 ms
Image modifyAlpha (SIMD on) 22.000 ms
Image modifyAlpha ratio (SIMD on/off) 0.710x (29.0% faster)
Image modifyAlpha removeColor (SIMD off) 34.000 ms
Image modifyAlpha removeColor (SIMD on) 57.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off) 1.676x (67.6% slower)

@shai-almog @claude
Skirmish: invite a friend, engagement through Codename One analytics …
75184d7 
…and push, the admin Promote tab

- Invites: com.codename1.analytics.invite links carrying the player's
  referral code; the friend's app reads the attribution on start and
  claims it after signing in. The server keeps only the economy: codes,
  who joined through whom, and the rewards (refused for old accounts,
  own codes and second claims; inviter paid after the friend's first
  battle, at most ten friends). first_battle/first_win conversions.
- Engagement is read in the Codename One analytics console: user
  properties for level and trophy band, invite and push-open events,
  AppReview after a win.
- Promote tab: opens the analytics console, broadcasts Codename One push
  to a segment with a campaign the app reports on open (counted and
  confirmed, five a day), the home spotlight banner, campaign links.
- The console's tabs are a side bar on desktop and tablet; run-e2e.sh
  runs a second, desktop pass on Linux for PromoteTest.
- E2e.click taps components that are not Buttons (ForgeHome's pack rows
  are MultiButtons, which failed ForgeTest); ShopForm ignores a load
  that finishes after sign-out.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
shai-almog and others added 7 commits October 22, 2026 10:23
@shai-almog @claude
Skirmish: growth tutorial, Promote screenshots in the e2e, seeded spo…
49d298a 
…tlight, LanguageTool and template fixes

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog @claude
Skirmish: transparent Forge/help labels, wrapping spotlight, scrollin…
5819606 
…g admin tabs on phones, ForgeTest mission id, guide prose

The e2e screenshots showed white boxes behind every Forge and Promote
label, help text and the invite code: those UIIDs were missing from the
theme's transparent list.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog @claude
Skirmish: Forge and engagement screenshots in the guides, ForgeTest's…
a34a9b3 
… new-pack mission, remaining white icon and value boxes

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog @claude
Skirmish e2e: scroll a row into view before tapping it; guide screens…
323d70d 
…hots from the restyled screens

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog @claude
Skirmish guide: screenshots at full guide width
8b34714 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog @claude
Skirmish e2e: 1536m for the simulator, TutorialTest ran out of heap a…
61b655e 
…fter the Forge tests

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog @claude
Skirmish growth tutorial: the desktop console's Promote tab, push com…
49727b9 
…poser, confirmation and spotlight

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog

shai-almog commented Oct 22, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Compared 193 screenshots: 193 matched.
Native Linux port (x64), GTK3/Cairo/Pango, ParparVM bytecode-to-C (no JVM): the hellocodenameone screenshot suite rendered by a native ELF built + run on the GitHub x64 runner. Baseline: scripts/linux/screenshots.

ParparVM vs HotSpot (JDK 25): Linux x64

Runner CPU: AMD EPYC 9V45 96-Core Processor (baseline linux-x64@amd-epyc-9v45-96-core-processor)

Ratios are ParparVM / JDK 25: below 1.00x ParparVM is faster (time) or smaller (RAM). Median of 5 interleaved, paired rounds; every run's output was verified. A ratio more than 20% (time) / 25% (RAM) above its baseline in vm/selfhost/perf-baseline/ is a regression and fails; one that far below is an improvement, reported but not failed (a row whose calibration runs were noisier carries a wider tolerance), and for RAM the change must also exceed 0.05x in absolute terms. Both run unpinned on all of the runner's CPUs, with their own default thread counts.

Benchmark Cores Time RAM Status
hello (LinuxHelloMain) 4 0.94x (base 0.92x, +2.0%) 0.87x (base 0.84x, +3.0%) ok
translator (self) 4 0.73x (base 0.64x, +14.5%) 0.54x (base 0.55x, -1.7%) ok
intArithmetic 4 1.00x (base 1.00x, +0.0%) 0.04x (base 0.06x, -30.9%) ok
longArithmetic 4 0.99x (base 0.99x, -0.1%) 0.04x (base 0.07x, -47.8%) ok
mathTranscendental 4 1.19x (base 1.20x, -0.5%) 0.04x (base 0.06x, -28.7%) ok
arraySequential 4 2.77x (base 2.91x, -4.6%) 0.36x (base 0.36x, +1.0%) ok
arrayRandom 4 1.01x (base 1.04x, -3.2%) 0.20x (base 0.23x, -11.0%) ok
objectAllocation 4 1.59x (base 1.61x, -1.1%) 0.29x (base 0.24x, +20.4%) ok
valueEscape 4 0.10x (base 0.12x, -13.1%) 0.03x (base 0.04x, -28.7%) ok
hashMapChurn 4 1.41x (base 1.31x, +7.6%) 0.09x (base 0.09x, +7.1%) ok
stringBuilding 4 1.51x (base 1.58x, -4.2%) 0.26x (base 0.22x, +20.3%) ok
recursion 4 1.31x (base 1.34x, -2.3%) 0.04x (base 0.08x, -46.5%) ok
quicksort 4 1.05x (base 1.06x, -1.4%) 0.10x (base 0.11x, -11.2%) ok

Result: no regression

@shai-almog

shai-almog commented Oct 22, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Compared 193 screenshots: 193 matched.
Native Linux port (arm64), GTK3/Cairo/Pango, ParparVM bytecode-to-C (no JVM): the hellocodenameone screenshot suite rendered by a native ELF built + run on the GitHub arm64 runner. Baseline: scripts/linux/screenshots-arm.

ParparVM vs HotSpot (JDK 25): Linux arm64

Runner CPU: Neoverse-N2 (baseline linux-arm64@neoverse-n2)

Ratios are ParparVM / JDK 25: below 1.00x ParparVM is faster (time) or smaller (RAM). Median of 5 interleaved, paired rounds; every run's output was verified. A ratio more than 20% (time) / 25% (RAM) above its baseline in vm/selfhost/perf-baseline/ is a regression and fails; one that far below is an improvement, reported but not failed (a row whose calibration runs were noisier carries a wider tolerance), and for RAM the change must also exceed 0.05x in absolute terms. Both run unpinned on all of the runner's CPUs, with their own default thread counts.

Benchmark Cores Time RAM Status
hello (LinuxHelloMain) 4 0.96x (base 1.02x, -5.8%) 0.78x (base 0.93x, -16.0%) ok
translator (self) 4 0.74x (base 0.70x, +6.2%) 0.44x (base 0.43x, +1.8%) ok
intArithmetic 4 1.04x (base 1.04x, -0.1%) 0.03x (base 0.03x, +4.7%) ok
longArithmetic 4 0.79x (base 0.79x, -0.1%) 0.03x (base 0.03x, +5.0%) ok
mathTranscendental 4 1.11x (base 1.10x, +0.7%) 0.04x (base 0.03x, +9.8%) ok
arraySequential 4 0.37x (base 0.36x, +2.1%) 0.37x (base 0.37x, +0.5%) ok
arrayRandom 4 0.93x (base 0.94x, -0.4%) 0.20x (base 0.20x, +1.0%) ok
objectAllocation 4 1.95x (base 1.77x, +10.1%) 0.37x (base 0.37x, +1.3%) ok
valueEscape 4 0.51x (base 0.51x, -0.1%) 0.03x (base 0.03x, +5.2%) ok
hashMapChurn 4 0.84x (base 0.84x, +0.1%) 0.11x (base 0.12x, -5.1%) ok
stringBuilding 4 1.49x (base 1.57x, -4.6%) 0.26x (base 0.26x, +0.3%) ok
recursion 4 1.56x (base 1.43x, +8.9%) 0.04x (base 0.04x, +3.1%) ok
quicksort 4 1.00x (base 0.99x, +1.0%) 0.09x (base 0.09x, +1.3%) ok

Result: no regression

@github-actions

github-actions Bot commented Oct 22, 2026

Copy link
Copy Markdown
Contributor

✅ ByteCodeTranslator Quality Report

Test & Coverage

  • ✅ Tests: 879 total, 0 failed, 57 skipped

Benchmark Results

  • Execution Time: 8947 ms

  • Hotspots (Top 20 sampled methods):

    • 12.90% com.codename1.tools.translator.IteratorEscape.mangle (170 samples)
    • 5.61% java.lang.System.identityHashCode (74 samples)
    • 4.63% java.util.ArrayList.indexOf (61 samples)
    • 4.02% com.codename1.tools.translator.BytecodeMethod.equals (53 samples)
    • 3.26% java.lang.Object.hashCode (43 samples)
    • 2.88% com.codename1.tools.translator.ByteCodeClass.fillVirtualMethodTable (38 samples)
    • 2.73% java.lang.StringBuilder.append (36 samples)
    • 2.66% java.lang.String.equals (35 samples)
    • 2.50% com.codename1.tools.translator.JavascriptReachability.enqueueResolved (33 samples)
    • 2.43% com.codename1.tools.translator.IteratorEscape.walk (32 samples)
    • 2.12% com.codename1.tools.translator.bytecodes.Invoke.findMethodUp (28 samples)
    • 1.82% java.util.HashMap.hash (24 samples)
    • 1.59% java.util.HashMap.putVal (21 samples)
    • 1.44% com.codename1.tools.translator.bytecodes.Invoke.resolveDirectTarget (19 samples)
    • 1.29% com.codename1.tools.translator.ReachabilityCull.run (17 samples)
    • 1.29% java.util.AbstractCollection.containsAll (17 samples)
    • 1.21% com.codename1.tools.translator.BytecodeMethod.addToConstantPool (16 samples)
    • 1.21% com.codename1.tools.translator.BytecodeMethod.updateInlinableFieldDependencies (16 samples)
    • 1.14% com.codename1.tools.translator.ByteCodeClass.hasDeclaredMethod (15 samples)
    • 1.06% com.codename1.tools.translator.Parser.cullMethods (14 samples)

  • ⚠️ Coverage report not generated.

Static Analysis

  • ✅ SpotBugs: no findings (report was not generated by the build).
  • ⚠️ PMD report not generated.
  • ⚠️ Checkstyle report not generated.

Generated automatically by the PR CI workflow.

shai-almog and others added 2 commits October 22, 2026 13:44
@shai-almog @claude
Merge master: Skirmish beside Parley as the fourth full-stack sample
ae51efd 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog @claude
Skirmish: desktop console with reports, query tool and engagement pip…
643a60f 
…elines; one implementor guide

The admin console is a native-looking desktop tool (Desk widgets, aligned
label column, light palette, side bar) with charts of daily players,
battles, gems, the funnel, retention and the trophy ladder; a query tool
over player records; and pipelines that act on matching players hourly
with a per-player cool-down. Forge labels get room and margins. The
users' guide is folded into the implementor guide.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog

shai-almog commented Oct 22, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Compared 179 screenshots: 179 matched.
✅ Native Mac screenshot tests passed.

Benchmark Results

  • VM Translation Time: 0 seconds
  • Compilation Time: 376 seconds

Detailed Performance Metrics

Metric Duration
SIMD kernel backend SSE2 (x64) / NEON (arm64) native kernels
SIMD int-add (64K x300) java 60ms / native 2ms = 30.0x speedup
SIMD float-mul (64K x300) java 57ms / native 3ms = 19.0x speedup
SIMD kernel correctness PASS (native result == scalar reference)
Base64 native bridge unavailable (CN1 + SIMD + image benchmarks only)
Base64 payload size 8192 bytes
Base64 benchmark iterations 6000
Base64 SIMD byte path active (NEON-accelerated)
Base64 CN1 encode 62.000 ms
Base64 CN1 decode 76.000 ms
Image encode benchmark iterations 100
Image createMask (SIMD off) 10.000 ms
Image createMask (SIMD on) 3.000 ms
Image createMask ratio (SIMD on/off) 0.300x (70.0% faster)
Image applyMask (SIMD off) 65.000 ms
Image applyMask (SIMD on) 68.000 ms
Image applyMask ratio (SIMD on/off) 1.046x (4.6% slower)
Image modifyAlpha (SIMD off) 88.000 ms
Image modifyAlpha (SIMD on) 88.000 ms
Image modifyAlpha ratio (SIMD on/off) 1.000x (0.0% slower)
Image modifyAlpha removeColor (SIMD off) 81.000 ms
Image modifyAlpha removeColor (SIMD on) 80.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off) 0.988x (1.2% faster)

ParparVM vs HotSpot (JDK 25): macOS arm64

Runner CPU: Apple M1 (Virtual) (baseline macos-arm64)

1 performance regression:

  • stringBuilding on all 3 CPUs: time 1.03x against a 0.84x baseline (+22.4%, tolerance 20%)

Ratios are ParparVM / JDK 25: below 1.00x ParparVM is faster (time) or smaller (RAM). Median of 5 interleaved, paired rounds; every run's output was verified. A ratio more than 20% (time) / 25% (RAM) above its baseline in vm/selfhost/perf-baseline/ is a regression and fails; one that far below is an improvement, reported but not failed (a row whose calibration runs were noisier carries a wider tolerance), and for RAM the change must also exceed 0.05x in absolute terms. Both run unpinned on all of the runner's CPUs, with their own default thread counts.

Benchmark Cores Time RAM Status
hello (HelloCodenameOne) 3 0.82x (base 0.96x, -14.4%) 0.94x (base 0.93x, +1.2%) ok
translator (self) 3 0.57x (base 0.62x, -7.9%) 0.71x (base 0.58x, +23.5%) ok
intArithmetic 3 1.05x (base 1.03x, +1.9%) 0.12x (base 0.12x, +2.0%) ok
longArithmetic 3 1.02x (base 1.03x, -0.2%) 0.12x (base 0.07x, +65.5%) ok
mathTranscendental 3 0.96x (base 1.01x, -4.7%) 0.12x (base 0.12x, +1.3%) ok
arraySequential 3 0.44x (base 0.42x, +4.5%) 0.53x (base 0.53x, +0.5%) ok
arrayRandom 3 0.99x (base 0.99x, +0.6%) 0.33x (base 0.32x, +0.4%) ok
objectAllocation 3 1.11x (base 1.11x, +0.5%) 0.83x (base 0.72x, +14.1%) ok
valueEscape 3 0.48x (base 0.51x, -4.8%) 0.09x (base 0.09x, -0.7%) ok
hashMapChurn 3 0.94x (base 1.18x, -20.5%) 0.07x (base 0.07x, +9.4%) ok
stringBuilding 3 1.03x (base 0.84x, +22.4%) 0.46x (base 0.46x, +0.0%) REGRESSION (time +22.4%)
recursion 3 1.27x (base 1.24x, +3.1%) 0.12x (base 0.12x, -1.7%) ok
quicksort 3 0.98x (base 1.01x, -3.3%) 0.11x (base 0.11x, +0.7%) ok

A change that moves performance ON PURPOSE records the new baseline in vm/selfhost/perf-baseline/pr/6074.json, with the reason, from this job's perf-results.json. The rebaseline is then part of this pull request's diff:

python3 vm/selfhost/calibrate-perf-baseline.py --pr 6074 --reason "<why these benchmarks moved>" perf-results.json

Result: performance regression

@shai-almog

shai-almog commented Oct 22, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Compared 236 screenshots: 236 matched.
✅ Native Apple Watch (watchOS, Core Graphics) screenshot tests passed.

@shai-almog

shai-almog commented Oct 22, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Compared 176 screenshots: 176 matched.
✅ Native iOS Metal screenshot tests passed.

Benchmark Results

  • VM Translation Time: 0 seconds
  • Compilation Time: 1891 seconds

Build and Run Timing

Metric Duration
Simulator Boot 84000 ms
Simulator Boot (Run) 16000 ms
App Install 19000 ms
App Launch 4000 ms
Test Execution 595000 ms

Detailed Performance Metrics

Metric Duration
SIMD kernel backend SSE2 (x64) / NEON (arm64) native kernels
SIMD int-add (64K x300) java 84ms / native 4ms = 21.0x speedup
SIMD float-mul (64K x300) java 80ms / native 3ms = 26.6x speedup
SIMD kernel correctness PASS (native result == scalar reference)
Base64 payload size 8192 bytes
Base64 benchmark iterations 6000
Base64 SIMD byte path active (NEON-accelerated)
Base64 CN1 encode 98.000 ms
Base64 CN1 decode 59.000 ms
Base64 native encode 2359.000 ms
Base64 encode ratio (CN1/native) 0.042x (95.8% faster)
Base64 native decode 1356.000 ms
Base64 decode ratio (CN1/native) 0.044x (95.6% faster)
Base64 SIMD encode 59.000 ms
Base64 encode ratio (SIMD/CN1) 0.602x (39.8% faster)
Base64 SIMD decode 51.000 ms
Base64 decode ratio (SIMD/CN1) 0.864x (13.6% faster)
Base64 encode ratio (SIMD/native) 0.025x (97.5% faster)
Base64 decode ratio (SIMD/native) 0.038x (96.2% faster)
Image encode benchmark iterations 100
Image createMask (SIMD off) 6.000 ms
Image createMask (SIMD on) 2.000 ms
Image createMask ratio (SIMD on/off) 0.333x (66.7% faster)
Image applyMask (SIMD off) 36.000 ms
Image applyMask (SIMD on) 32.000 ms
Image applyMask ratio (SIMD on/off) 0.889x (11.1% faster)
Image modifyAlpha (SIMD off) 39.000 ms
Image modifyAlpha (SIMD on) 55.000 ms
Image modifyAlpha ratio (SIMD on/off) 1.410x (41.0% slower)
Image modifyAlpha removeColor (SIMD off) 62.000 ms
Image modifyAlpha removeColor (SIMD on) 344.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off) 5.548x (454.8% slower)

shai-almog and others added 3 commits October 22, 2026 19:04
@shai-almog @claude
Skirmish: compiled-backend fix, console chart/condition alignment, gu…
d14a5d1 
…ide section on reports, queries and pipelines

String.split is not in the compiled backend's runtime, so Audience splits by
hand. The two-series legend gets its own row, funnel labels are shorter, and
the condition rows share one joint-label width. The guide gains the console's
Reports, Query and Pipelines screenshots from CI, and LanguageTool's two
matches are reworded.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog @claude
Skirmish guide: reword the Count players sentence for LanguageTool
41a049b 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog @claude
Skirmish: the progress view never inserts the row, a legend row under…
29b6f33 
… two-series charts, refreshed console screenshots

On MySQL the first battle's result, recorded on the match ticker's thread, and
a progress read could both insert the player's progress row; the second insert
waited on the uncommitted row and failed with a duplicate key. Reading now
answers a fresh row without storing it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog
shai-almog merged commit 99a52c0 into master Oct 22, 2026
80 of 104 checks passed
@shai-almog
shai-almog deleted the skirmish-game-sample branch October 22, 2026 18:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@shai-almog