Skip to content

Developer guide: restore 19 dropped code examples as compiled snippets - #5711

Merged
shai-almog merged 7 commits into
masterfrom
devguide-restore-blocks
Sep 5, 2026
Merged

shai-almog merged 7 commits into
masterfrom
devguide-restore-blocks

Conversation

@shai-almog

Copy link
Copy Markdown
Collaborator

bbdc6058f0 converted inline listings into include:: directives and dropped roughly 415 of them, leaving the introducing sentence, its colon and two blank lines where the code had been. This restores 19 of them across five chapters, verbatim from bbdc6058f0~1, as snippets that compile in the demos module.

Restoring the code rather than deleting the promise is the point. Every sample now compiles against the current core, so the guide can't claim an API that isn't there. Three defects only a compiler was going to find:

  • the samples use com.codename1.sensors, com.codename1.car and com.codename1.nfc -- none of which the shared snippet preamble imports;
  • "Daft Punk — Discovery" carried a literal em dash into a .java file, which javac -encoding ascii rejects outright;
  • two NFC bodies needed reshaping. A body opening with new NfcReadOptions() reads as a method signature to the extractor's shape classifier, so it was emitted at class level and wouldn't parse. A local class inside snippet() is legal Java and keeps the published sample byte-identical.

One near-miss worth recording: setIsoSelectAids(myAid) failed to compile, which looked like the guide documenting a signature that doesn't exist. It was my scaffolding -- an AID is a byte[], and the real signature is setIsoSelectAids(byte[]...). The sample was right. Checked before "fixing" the guide.

Four holes in these chapters are deliberately left in the baseline, because the code is real but doesn't belong on this module's classpath:

Holes Why
Deep-Links-Routing 003/004 use com.codename1.maven.routing.AasaBuilder, which lives in the maven plugin -- build-time tooling, not app code
Monetization (7) the demo server's receipt validation: needs the cn1-generic-webservice-client cn1lib and Java EE (@Stateless, EntityManager)

Adding either dependency to the demos module to satisfy a doc build would be the tail wagging the dog. Those need their own decision, so they stay recorded as holes rather than being quietly dropped.

Ratchet: 89 → 70, deletions only. Verified: mvn process-classes on docs/demos builds all 685 sources (this needed a core rebuild locally -- the demos tree on master already uses NativeDragAndDrop from #5662).

Disjoint from #5710: different chapters, different baseline file.

🤖 Generated with Claude Code

bbdc605 converted inline listings into include:: directives and left the
introducing sentence, its colon and two blank lines where the code had been.
This restores them for five chapters, verbatim from bbdc605~1, as compiled
snippets in the demos module.

Restoring code rather than deleting the promise is what makes this worth doing:
every sample now compiles against the current core, so the guide cannot claim an
API that isn't there. Three things only a compiler was going to find:

  - the samples use com.codename1.sensors, com.codename1.car and
    com.codename1.nfc, none of which the shared snippet preamble imported
  - "Daft Punk -- Discovery" carried a literal em dash into a .java file, which
    javac -encoding ascii rejects outright
  - two NFC bodies were reshaped: a body opening with `new NfcReadOptions()`
    reads as a method signature to the extractor's classifier, so it was placed
    at class level and would not parse. A local class inside snippet() is legal
    Java and keeps the published sample byte-identical.

Four holes in these chapters are deliberately left in the baseline, because the
code is real but does not belong on this module's classpath:

  - Deep-Links-Routing 003/004 use com.codename1.maven.routing.AasaBuilder,
    which lives in the maven plugin. It is build-time tooling, not app code.
  - Monetization's seven holes are the demo server's receipt validation, which
    needs the cn1-generic-webservice-client cn1lib and Java EE.

Adding either dependency to the demos module to satisfy a doc build would be the
tail wagging the dog; those need their own decision.

Baseline: 89 -> 70, deletions only.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Sep 5, 2026 •

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ✅ Completed 2026-09-05T18:22:32.702391Z ea1229a New commits
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6b4e83e68a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

These came back verbatim from bbdc605~1, and restoring them faithfully is not
a reason to republish code that does not work. All three were wrong in the
original:

  - the accelerometer sample registered an anonymous MotionSensorListener while
    the very next sample tells the reader to call removeListener(listener).
    MotionSensor holds that exact object, so as written the listener could never
    be removed and the sensor kept drawing power. It is now a named local.

  - the FeliCa sample built an NfcReadOptions and discarded it. It configured
    nothing and started no read; the options only take effect when passed to
    readTag, which is where they now go.

  - the dirty-form PopGuard threw away the dialog result and returned false
    unconditionally, so "Discard" behaved exactly like "Stay" and the form could
    not be left at all. Dialog.show returns true for the first button, so the
    guard returns its negation.

Compiling the restored code found the API mismatches; these three needed reading
the sample against what the API does, because each one compiles perfectly and
still does not work.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 5d991a489e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

@github-actions

github-actions Bot commented Sep 5, 2026 •

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)

…false

Five more defects in the restored samples, all of which compile:

  - the accelerometer listener was a method local, so the removeNotify the next
    sample tells you to write cannot reach it. Both the sensor and the listener
    are fields now.
  - that removal dereferenced a sensor the previous sample explicitly says can
    be null, so leaving the form on a device without an accelerometer threw.
  - the shake sample registered an anonymous GestureListener with no way to
    unregister it. MotionSensorManager keeps the accelerometer powered while any
    gesture listener is registered, so the sample now shows both halves.
  - the tabletop layout branched on isTableTop(), which is
    POSTURE_HALF_OPENED && isSeparating() -- true for book posture on a
    vertically hinged device, where a top/bottom split is wrong. It now also
    requires FOLD_ORIENTATION_HORIZONTAL.

The last one is not a sample bug at all. The chapter said the Maven plugin and
build daemon "automatically register
com.apple.developer.nfc.readersession.felica.systemcodes from these values".
They do not. IPhoneBuilder injects CoreNFC, a default NFCReaderUsageDescription
and the readersession.formats entitlement when it sees com.codename1.nfc on the
classpath, and neither this repo nor BuildDaemon mentions felica anywhere. Nor
could it: the codes are an argument to setFelicaSystemCodes at runtime, which no
build-time classpath scan can observe. An app built by following that sentence
cannot read FeliCa on iOS.

The chapter now says what to set, using the ios.entitlements.* namespace the
generic renderer already emits. NfcF's javadoc made the same claim in the same
words -- that is where the sentence came from -- so it is corrected too, or the
guide would just inherit it again. TagType's wording was already right.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f2ddfe34c3

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

@github-actions

github-actions Bot commented Sep 5, 2026

Copy link
Copy Markdown
Contributor

Cloudflare Preview

…list

Three things, one of them a mistake I made two commits ago.

The FeliCa system codes and the ISO 7816 select identifiers are Info.plist
keys, not entitlements. Only readersession.formats is an entitlement. My
previous fix told the reader to set the FeliCa codes under ios.entitlements.*,
which would put them in the wrong file and still not work. Both are now
ios.plistInject, with the plist XML spelled out, in the chapter and in NfcF's
javadoc.

setIsoSelectAids has exactly the same gap as setFelicaSystemCodes and it was not
documented at all: Core NFC only discovers an ISO 7816 application the app
declared up front, and no builder derives that key from the runtime call.
Note the builders DO handle nfc.hce.iso7816.select-identifiers -- that is the
host card emulation key, a different one, and the near miss is worth calling out
because grepping for "iso7816" finds it and suggests the case is covered.

The head-unit row limit was assigned to a local and never used, while the prose
above it says to trim accordingly. It now caps the loop, treating 0 as unknown.
Written with an index loop rather than a List local because the snippet fixture
imports both java.util and com.codename1.ui.list, so a bare List is ambiguous.
@github-actions

github-actions Bot commented Sep 5, 2026 •

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)
    • ✅ build-hint-catalog: 0 findings (no issues)
    • ✅ build-hint-tools: 0 findings (no issues)
    • ✅ codenameone-maven-plugin: 0 findings (no issues)
    • ✅ core-unittests: 0 findings (no issues)
    • ✅ ios: 0 findings (no issues)
  • ✅ PMD: 0 findings (no issues) [Report archive]
  • ✅ Checkstyle: 0 findings (no issues) [Report archive]

Generated automatically by the PR CI workflow.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: cb4d6ea725

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

The chapter told the reader to unregister the sensor listener "from the form's
removeNotify". There is no such method: Component has deinitialize() and
initComponent(), Form adds hideNotify(). removeNotify is Swing. Following that
sentence produces either a compile error with @OverRide or a method nothing ever
calls, and either way the listener stays registered and the accelerometer stays
powered after the screen goes away.

The prose now names deinitialize(), and the samples put the fields somewhere the
teardown can actually reach them: registration is initComponent() on a Form
subclass, removal is the matching deinitialize().

The posture listener had the same defect for the same reason -- registered as a
lambda with nothing holding it, so CN.removePostureListener could never be
handed the same instance, and CN registers on the singleton Display, so every
recreated screen stayed reachable and kept receiving posture changes. It is a
field now, added and removed in the pair of hooks.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 40a9eb9b89

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

My own fix from three commits ago was wrong in a way that loses user data.

Dialog.show builds its commands as {cancelText, okText} and calls
setBackCommand(cmds[0]), so the hardware back key fires the CANCEL command and
show() returns false. With "Stay" as ok and "Discard" as cancel, plus the
inversion I added, backing out of the dialog returned true and the pop went
ahead -- the user never chose Discard and lost the edits anyway.

Discard is now the ok command and Stay the cancel command, and the result is
returned directly. Dismissal fires Stay, returns false, and the guard blocks the
pop, so the accident-safe outcome is the one the back key produces.

Audited the rest of the batch for both classes rather than waiting to be told.
The other Dialog.show passes null for cancelText, so it always returns true and
its result is unused. Of the listener registrations, three are component-scoped
and die with the component; Car.addConnectionListener is static like the posture
one, so it keeps a reference now. The HCE registration is left alone on purpose:
unregisterHostCardEmulationService takes no argument, so nothing needs holding.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6cb2ba5359

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

I made this a local variable one commit ago while writing a comment saying it
has to be handed back to Car.removeConnectionListener at teardown, which a local
cannot be. That is the same field-vs-local mistake I was already corrected on
for the accelerometer earlier in this branch, repeated after the correction.

It is now a field on a Form subclass with initComponent/deinitialize, matching
the accelerometer and posture samples. Car keeps listeners in a static list, so
without this every recreated screen stays reachable and keeps receiving
connection callbacks.

Swept the whole batch for the pattern rather than fixing the one that was
reported: all four retained listeners are fields.
@shai-almog
shai-almog merged commit f4a6c92 into master Sep 5, 2026
29 of 30 checks passed
@shai-almog
shai-almog deleted the devguide-restore-blocks branch September 5, 2026 18:30
@shai-almog

shai-almog commented Sep 5, 2026 •

Copy link
Copy Markdown
Collaborator Author

Compared 151 screenshots: 151 matched.

Native Android coverage

  • 📊 Line coverage: 9.14% (9061/99176 lines covered) [HTML preview] (artifact android-coverage-report, jacocoAndroidReport/html/index.html)
    • Other counters: instruction 8.91% (46674/523952), branch 3.50% (1739/49639), complexity 3.49% (1849/52940), method 5.37% (1496/27852), class 10.81% (403/3727)
    • 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)
      • kotlin.collections.kotlin.collections.CollectionsKt___CollectionsKt – 0.00% (0/1187 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)
      • org.jacoco.agent.rt.internal_0e20598.asm.org.jacoco.agent.rt.internal_0e20598.asm.Frame – 0.00% (0/570 lines covered)

✅ Native Android screenshot tests passed.

Native Android coverage

  • 📊 Line coverage: 9.14% (9061/99176 lines covered) [HTML preview] (artifact android-coverage-report, jacocoAndroidReport/html/index.html)
    • Other counters: instruction 8.91% (46674/523952), branch 3.50% (1739/49639), complexity 3.49% (1849/52940), method 5.37% (1496/27852), class 10.81% (403/3727)
    • 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)
      • kotlin.collections.kotlin.collections.CollectionsKt___CollectionsKt – 0.00% (0/1187 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)
      • org.jacoco.agent.rt.internal_0e20598.asm.org.jacoco.agent.rt.internal_0e20598.asm.Frame – 0.00% (0/570 lines covered)

Benchmark Results

Detailed Performance Metrics

Metric Duration
SIMD kernel backend scalar fallback (no native SIMD)
SIMD int-add (64K x300) java 250ms / native 182ms = 1.3x speedup
SIMD float-mul (64K x300) java 212ms / native 150ms = 1.4x 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 101.000 ms
Base64 CN1 decode 84.000 ms
Base64 native encode 422.000 ms
Base64 encode ratio (CN1/native) 0.239x (76.1% faster)
Base64 native decode 283.000 ms
Base64 decode ratio (CN1/native) 0.297x (70.3% faster)
Image encode benchmark status skipped (SIMD unsupported)

@shai-almog

shai-almog commented Sep 5, 2026 •

Copy link
Copy Markdown
Collaborator Author

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

Benchmark Results

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

Detailed Performance Metrics

Metric Duration
SIMD kernel backend SSE2 (x64) / NEON (arm64) native kernels
SIMD int-add (64K x300) java 60ms / native 3ms = 20.0x speedup
SIMD float-mul (64K x300) java 61ms / native 3ms = 20.3x 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 144.000 ms
Base64 CN1 decode 86.000 ms
Image encode benchmark iterations 100
Image createMask (SIMD off) 6.000 ms
Image createMask (SIMD on) 1.000 ms
Image createMask ratio (SIMD on/off) 0.167x (83.3% faster)
Image applyMask (SIMD off) 38.000 ms
Image applyMask (SIMD on) 28.000 ms
Image applyMask ratio (SIMD on/off) 0.737x (26.3% faster)
Image modifyAlpha (SIMD off) 31.000 ms
Image modifyAlpha (SIMD on) 28.000 ms
Image modifyAlpha ratio (SIMD on/off) 0.903x (9.7% faster)
Image modifyAlpha removeColor (SIMD off) 34.000 ms
Image modifyAlpha removeColor (SIMD on) 28.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off) 0.824x (17.6% faster)

@shai-almog

shai-almog commented Sep 5, 2026 •

Copy link
Copy Markdown
Collaborator Author

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

Benchmark Results

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

Detailed Performance Metrics

Metric Duration
SIMD kernel backend SSE2 (x64) / NEON (arm64) native kernels
SIMD int-add (64K x300) java 59ms / native 2ms = 29.5x speedup
SIMD float-mul (64K x300) java 63ms / native 3ms = 21.0x 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 217.000 ms
Base64 CN1 decode 127.000 ms
Base64 native encode 1079.000 ms
Base64 encode ratio (CN1/native) 0.201x (79.9% faster)
Base64 native decode 547.000 ms
Base64 decode ratio (CN1/native) 0.232x (76.8% faster)
Base64 SIMD encode 63.000 ms
Base64 encode ratio (SIMD/CN1) 0.290x (71.0% faster)
Base64 SIMD decode 59.000 ms
Base64 decode ratio (SIMD/CN1) 0.465x (53.5% faster)
Base64 encode ratio (SIMD/native) 0.058x (94.2% faster)
Base64 decode ratio (SIMD/native) 0.108x (89.2% faster)
Image encode benchmark iterations 100
Image createMask (SIMD off) 13.000 ms
Image createMask (SIMD on) 5.000 ms
Image createMask ratio (SIMD on/off) 0.385x (61.5% faster)
Image applyMask (SIMD off) 93.000 ms
Image applyMask (SIMD on) 93.000 ms
Image applyMask ratio (SIMD on/off) 1.000x (0.0% slower)
Image modifyAlpha (SIMD off) 88.000 ms
Image modifyAlpha (SIMD on) 85.000 ms
Image modifyAlpha ratio (SIMD on/off) 0.966x (3.4% faster)
Image modifyAlpha removeColor (SIMD off) 89.000 ms
Image modifyAlpha removeColor (SIMD on) 80.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off) 0.899x (10.1% faster)

@shai-almog

shai-almog commented Sep 5, 2026 •

Copy link
Copy Markdown
Collaborator Author

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

Benchmark Results

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

Build and Run Timing

Metric Duration
Simulator Boot 82000 ms
Simulator Boot (Run) 1000 ms
App Install 13000 ms
App Launch 5000 ms
Test Execution 371000 ms

Detailed Performance Metrics

Metric Duration
SIMD kernel backend SSE2 (x64) / NEON (arm64) native kernels
SIMD int-add (64K x300) java 55ms / native 3ms = 18.3x speedup
SIMD float-mul (64K x300) java 73ms / native 3ms = 24.3x 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 189.000 ms
Base64 CN1 decode 101.000 ms
Base64 native encode 1181.000 ms
Base64 encode ratio (CN1/native) 0.160x (84.0% faster)
Base64 native decode 617.000 ms
Base64 decode ratio (CN1/native) 0.164x (83.6% faster)
Base64 SIMD encode 56.000 ms
Base64 encode ratio (SIMD/CN1) 0.296x (70.4% faster)
Base64 SIMD decode 47.000 ms
Base64 decode ratio (SIMD/CN1) 0.465x (53.5% faster)
Base64 encode ratio (SIMD/native) 0.047x (95.3% faster)
Base64 decode ratio (SIMD/native) 0.076x (92.4% faster)
Image encode benchmark iterations 100
Image createMask (SIMD off) 31.000 ms
Image createMask (SIMD on) 35.000 ms
Image createMask ratio (SIMD on/off) 1.129x (12.9% slower)
Image applyMask (SIMD off) 179.000 ms
Image applyMask (SIMD on) 201.000 ms
Image applyMask ratio (SIMD on/off) 1.123x (12.3% slower)
Image modifyAlpha (SIMD off) 324.000 ms
Image modifyAlpha (SIMD on) 226.000 ms
Image modifyAlpha ratio (SIMD on/off) 0.698x (30.2% faster)
Image modifyAlpha removeColor (SIMD off) 241.000 ms
Image modifyAlpha removeColor (SIMD on) 151.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off) 0.627x (37.3% faster)

@shai-almog

shai-almog commented Sep 5, 2026 •

Copy link
Copy Markdown
Collaborator Author

Compared 144 screenshots: 144 matched.
✅ Native Apple TV (tvOS, Metal) screenshot tests passed.

@shai-almog

shai-almog commented Sep 5, 2026 •

Copy link
Copy Markdown
Collaborator Author

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

@shai-almog

shai-almog commented Sep 6, 2026 •

Copy link
Copy Markdown
Collaborator Author

Compared 143 screenshots: 143 matched.
✅ Native iOS screenshot tests passed.

Benchmark Results

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

Build and Run Timing

Metric Duration
Simulator Boot 93000 ms
Simulator Boot (Run) 1000 ms
App Install 19000 ms
App Launch 40000 ms
Test Execution 476000 ms

Detailed Performance Metrics

Metric Duration
SIMD kernel backend SSE2 (x64) / NEON (arm64) native kernels
SIMD int-add (64K x300) java 54ms / native 3ms = 18.0x speedup
SIMD float-mul (64K x300) java 54ms / native 2ms = 27.0x 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 180.000 ms
Base64 CN1 decode 727.000 ms
Base64 native encode 1399.000 ms
Base64 encode ratio (CN1/native) 0.129x (87.1% faster)
Base64 native decode 2170.000 ms
Base64 decode ratio (CN1/native) 0.335x (66.5% faster)
Base64 SIMD encode 409.000 ms
Base64 encode ratio (SIMD/CN1) 2.272x (127.2% slower)
Base64 SIMD decode 173.000 ms
Base64 decode ratio (SIMD/CN1) 0.238x (76.2% faster)
Base64 encode ratio (SIMD/native) 0.292x (70.8% faster)
Base64 decode ratio (SIMD/native) 0.080x (92.0% 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) 48.000 ms
Image applyMask (SIMD on) 125.000 ms
Image applyMask ratio (SIMD on/off) 2.604x (160.4% slower)
Image modifyAlpha (SIMD off) 72.000 ms
Image modifyAlpha (SIMD on) 98.000 ms
Image modifyAlpha ratio (SIMD on/off) 1.361x (36.1% slower)
Image modifyAlpha removeColor (SIMD off) 59.000 ms
Image modifyAlpha removeColor (SIMD on) 55.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off) 0.932x (6.8% faster)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant