JavaScript port: never read the display canvas back (#6123) by shai-almog · Pull Request #6124 · codenameone/CodenameOne

shai-almog · 2026-10-28T03:04:23Z

Cause. HTML5Implementation.hitTest() read one pixel back from the display canvas (a worker round trip and a getImageData) on every touchstart, mousedown and wheel event. It did this even in an application with no native peers, where every caller discards the result. Chrome counts readbacks per canvas context and, after a couple, logs "Multiple readback operations using getImageData are faster with the willReadFrequently attribute set to true" and moves the canvas off the GPU for good. Every later frame of the full-screen canvas was then drawn in software: about 80 ms a frame on the reporter's Samsung A20e, against 16 ms on an iPhone, since Safari has no such heuristic.

Fix.

hitTest() returns true without probing unless native peers are painted behind the canvas.
The readbacks that remain go through a new readCanvasPixels in browser_bridge.js: getRGB of a surface, the peer pointer toggle, and the lens, glass and color-matrix self-region effects. It copies the region into a scratch willReadFrequently canvas and reads that, so the source canvas is never read in place. The pixel values are identical, and out-of-bounds pixels read as transparent. The scratch is dropped after any read above 1M pixels.

Test. test-javascript-composited-rendering.mjs, which already drives a peer-free app in CI, now fails if a wheel, repeated mouse drags or repeated phone swipes cause any worker __cn1_surface_read__ request or any getImageData on the display canvas. The gestures are repeated because the first press of a page never probed: a single gesture passes even with the bug in place.

Verified locally.

Rebuilt the issue's nine-row app from this tree. Before the fix, Chrome logs the readback warning and a swipe guard reports 1 surface read and 1 display getImageData. After the fix it reports 0 and 0.
verify-javascript-lens-parity.mjs: 0 failures. test-javascript-surface-replay.mjs passes.
In real Chromium, readCanvasPixels returns the same bytes as getImageData and does not trigger the warning; a direct getImageData does.

Not verified. The frame rate on a physical low-end Android phone. Headless Chrome cannot show the cost of software rasterization.

🤖 Generated with Claude Code

Every touchstart, mousedown and wheel event ran hitTest(), a 1x1 pixel read-back of the display canvas through a worker round trip, even in an application with no native peers, where every caller ignores the answer. Chrome counts getImageData calls per context and after a couple moves the canvas off the GPU for good, so every later frame was rasterized in software: a nine-row form scrolled at ~12fps on a budget Android phone. - hitTest() answers true without probing unless native peers are painted behind the canvas. - Reads that remain (getRGB of a surface, the peer pointer toggle, and the lens/glass/colour-matrix self-region effects) go through readCanvasPixels, which copies the region into a scratch canvas and reads that, so the source canvas is never read in place. - The composited rendering check now fails if a wheel, repeated mouse drags or repeated phone swipes read anything back from the display of its peer-free app. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

github-actions · 2026-10-28T03:21:05Z

Cloudflare Preview

URL: https://pr-6124-website-preview.codenameone.pages.dev
Branch: pr-6124-website-preview

new ConnectionRequest() asks the platform whether it supports access points, so the test passed only when an earlier test class in the same JVM had installed a port and failed with a NullPointerException whenever surefire ran it first. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

shai-almog · 2026-10-28T03:49:03Z

Compared 206 screenshots: 206 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 70ms / native 5ms = 14.0x speedup
SIMD float-mul (64K x300)	java 85ms / native 4ms = 21.2x 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	74.000 ms
Base64 CN1 decode	94.000 ms
Base64 SIMD encode	113.000 ms
Base64 encode ratio (SIMD/CN1)	1.527x (52.7% slower)
Base64 SIMD decode	103.000 ms
Base64 decode ratio (SIMD/CN1)	1.096x (9.6% slower)
Image encode benchmark iterations	100
Image createMask (SIMD off)	9.000 ms
Image createMask (SIMD on)	2.000 ms
Image createMask ratio (SIMD on/off)	0.222x (77.8% faster)
Image applyMask (SIMD off)	28.000 ms
Image applyMask (SIMD on)	30.000 ms
Image applyMask ratio (SIMD on/off)	1.071x (7.1% slower)
Image modifyAlpha (SIMD off)	33.000 ms
Image modifyAlpha (SIMD on)	20.000 ms
Image modifyAlpha ratio (SIMD on/off)	0.606x (39.4% faster)
Image modifyAlpha removeColor (SIMD off)	31.000 ms
Image modifyAlpha removeColor (SIMD on)	16.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off)	0.516x (48.4% faster)

shai-almog · 2026-10-28T03:49:57Z

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

github-actions · 2026-10-28T04:18:46Z

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)

github-actions · 2026-10-28T05:01:00Z

✅ Continuous Quality Report

Test & Coverage

✅ Tests: 14672 total, 0 failed, 161 skipped
📊 Line coverage: 64.86% [HTML preview] [Download]
- Lowest covered classes
  - com.codename1.io.zip.ZipArchiveOutputStream – 0.00%
  - com.codename1.gaming.level.GameSceneView – 0.00%
  - com.codename1.crash.CrashProtection – 0.00%
  - com.codename1.mapping.JsonValues – 0.00%
  - com.codename1.payment.CommerceManager – 0.00%
  - com.codename1.io.outbox.Outbox – 0.00%
  - com.codename1.security.CertificateRequest – 0.00%
  - com.codename1.wearable.WearableMessage – 0.00%
  - com.codename1.ui.plaf.GlassLensBlend – 0.00%
  - com.codename1.vr.VRView – 0.00%

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)
- ✅ desktop-compat-runtime: 0 findings (no issues)
- ✅ fxml-compiler: 0 findings (no issues)
- ✅ ios: 0 findings (no issues)
- ✅ javac: 0 findings (no issues)
- ✅ javafx-compat: 0 findings (no issues)
- ✅ project-model: 0 findings (no issues)
- ✅ swing-compat: 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.

shai-almog · 2026-10-28T05:22:29Z

Compared 206 screenshots: 206 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 31ms / native 3ms = 10.3x speedup
SIMD float-mul (64K x300)	java 30ms / native 2ms = 15.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	gated to scalar (CPU autovectorizes scalar; explicit SIMD not beneficial here)
Base64 CN1 encode	38.000 ms
Base64 CN1 decode	47.000 ms
Base64 SIMD encode	55.000 ms
Base64 encode ratio (SIMD/CN1)	1.447x (44.7% slower)
Base64 SIMD decode	55.000 ms
Base64 decode ratio (SIMD/CN1)	1.170x (17.0% slower)
Image encode benchmark iterations	100
Image createMask (SIMD off)	5.000 ms
Image createMask (SIMD on)	2.000 ms
Image createMask ratio (SIMD on/off)	0.400x (60.0% faster)
Image applyMask (SIMD off)	22.000 ms
Image applyMask (SIMD on)	15.000 ms
Image applyMask ratio (SIMD on/off)	0.682x (31.8% faster)
Image modifyAlpha (SIMD off)	22.000 ms
Image modifyAlpha (SIMD on)	10.000 ms
Image modifyAlpha ratio (SIMD on/off)	0.455x (54.5% faster)
Image modifyAlpha removeColor (SIMD off)	22.000 ms
Image modifyAlpha removeColor (SIMD on)	17.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off)	0.773x (22.7% faster)

ParparVM vs HotSpot (JDK 25): Windows x64

Runner CPU: AMD64 Family 26 Model 2 Stepping 1, AuthenticAMD (baseline windows-x64@amd64-family-26-model-2-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.48x (base 1.41x, +5.3%)	0.57x (base 0.68x, -16.5%)	ok
translator (self)	4	0.85x (base 0.90x, -5.4%)	0.46x (base 0.47x, -1.9%)	ok
intArithmetic	4	1.00x (base 0.99x, +0.9%)	0.06x (base 0.05x, +2.6%)	ok
longArithmetic	4	0.99x (base 0.99x, +0.3%)	0.06x (base 0.05x, +2.9%)	ok
mathTranscendental	4	0.93x (base 0.94x, -0.1%)	0.06x (base 0.06x, +2.1%)	ok
arraySequential	4	1.74x (base 1.75x, -0.6%)	0.38x (base 0.38x, +0.1%)	ok
arrayRandom	4	0.96x (base 1.00x, -4.4%)	0.23x (base 0.23x, +0.6%)	ok
objectAllocation	4	1.57x (base 1.65x, -4.7%)	0.29x (base 0.21x, +36.4%)	ok
valueEscape	4	0.10x (base 0.10x, +0.2%)	0.05x (base 0.04x, +3.0%)	ok
hashMapChurn	4	1.73x (base 1.59x, +8.6%)	0.09x (base 0.09x, -0.8%)	ok
stringBuilding	4	1.40x (base 1.39x, +1.2%)	0.32x (base 0.27x, +20.8%)	ok
recursion	4	1.42x (base 1.44x, -1.2%)	0.06x (base 0.06x, +2.7%)	ok
quicksort	4	1.09x (base 1.06x, +2.8%)	0.12x (base 0.12x, +1.3%)	ok

Result: no regression

shai-almog · 2026-10-28T05:39:10Z

Compared 206 screenshots: 206 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 7763 64-Core Processor (baseline linux-x64@amd-epyc-7763-64-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.85x (base 0.85x, +0.3%)	0.64x (base 0.83x, -23.0%)	ok
translator (self)	4	0.52x (base 0.64x, -19.1%)	0.47x (base 0.52x, -9.2%)	ok
intArithmetic	4	1.10x (base 1.12x, -1.2%)	0.06x (base 0.06x, -0.3%)	ok
longArithmetic	4	1.14x (base 1.08x, +5.2%)	0.06x (base 0.05x, +5.5%)	ok
mathTranscendental	4	1.08x (base 1.08x, -0.1%)	0.08x (base 0.07x, +3.8%)	ok
arraySequential	4	2.26x (base 2.00x, +12.7%)	0.36x (base 0.36x, -0.3%)	ok
arrayRandom	4	1.03x (base 0.91x, +13.7%)	0.21x (base 0.21x, +2.1%)	ok
objectAllocation	4	1.72x (base 1.65x, +4.3%)	0.26x (base 0.35x, -27.7%)	ok
valueEscape	4	0.10x (base 0.10x, -0.3%)	0.05x (base 0.04x, +4.4%)	ok
hashMapChurn	4	1.51x (base 1.48x, +2.1%)	0.10x (base 0.09x, +2.4%)	ok
stringBuilding	4	1.45x (base 1.39x, +4.1%)	0.26x (base 0.31x, -16.6%)	ok
recursion	4	1.39x (base 1.25x, +10.5%)	0.06x (base 0.08x, -23.9%)	ok
quicksort	4	1.09x (base 1.07x, +1.4%)	0.13x (base 0.11x, +15.1%)	ok

Result: no regression

shai-almog · 2026-10-28T05:39:15Z

Compared 206 screenshots: 206 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.93x (base 1.02x, -8.5%)	0.65x (base 0.93x, -30.5%)	ok
translator (self)	4	0.75x (base 0.70x, +7.2%)	0.44x (base 0.43x, +1.7%)	ok
intArithmetic	4	1.05x (base 1.04x, +0.0%)	0.03x (base 0.03x, +4.4%)	ok
longArithmetic	4	0.79x (base 0.79x, +0.0%)	0.03x (base 0.03x, +5.2%)	ok
mathTranscendental	4	1.10x (base 1.10x, +0.0%)	0.04x (base 0.03x, +9.7%)	ok
arraySequential	4	0.35x (base 0.36x, -3.0%)	0.37x (base 0.37x, +0.3%)	ok
arrayRandom	4	0.94x (base 0.94x, +0.7%)	0.20x (base 0.20x, +0.6%)	ok
objectAllocation	4	1.98x (base 1.77x, +12.0%)	0.36x (base 0.37x, -1.7%)	ok
valueEscape	4	0.51x (base 0.51x, -0.1%)	0.03x (base 0.03x, +5.9%)	ok
hashMapChurn	4	0.85x (base 0.84x, +1.4%)	0.12x (base 0.12x, -4.8%)	ok
stringBuilding	4	1.49x (base 1.57x, -5.2%)	0.26x (base 0.26x, +0.1%)	ok
recursion	4	1.42x (base 1.43x, -1.0%)	0.04x (base 0.04x, +2.9%)	ok
quicksort	4	1.02x (base 0.99x, +2.5%)	0.10x (base 0.09x, +2.5%)	ok

Result: no regression

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

github-actions · 2026-10-28T07:22:17Z

✅ ByteCodeTranslator Quality Report

Test & Coverage

✅ Tests: 882 total, 0 failed, 55 skipped

Benchmark Results

Execution Time: 6227 ms
Hotspots (Top 20 sampled methods):
- 9.81% com.codename1.tools.translator.IteratorEscape.ctorOnlyStoresParamsIntoThis (94 samples)
- 7.41% java.util.ArrayList.indexOf (71 samples)
- 5.43% java.lang.System.identityHashCode (52 samples)
- 3.97% com.codename1.tools.translator.classfile.analysis.Frame.execute (38 samples)
- 3.76% com.codename1.tools.translator.BytecodeMethod.equals (36 samples)
- 3.44% java.lang.StringBuilder.append (33 samples)
- 2.82% com.codename1.tools.translator.IteratorEscape.mangle (27 samples)
- 2.61% java.lang.Object.hashCode (25 samples)
- 2.51% com.codename1.tools.translator.Parser.cullMethods (24 samples)
- 1.77% com.codename1.tools.translator.BytecodeMethod.updateInlinableFieldDependencies (17 samples)
- 1.46% com.codename1.tools.translator.ReachabilityCull.run (14 samples)
- 1.46% com.codename1.tools.translator.bytecodes.Invoke.resolveDirectTarget (14 samples)
- 1.36% com.codename1.tools.translator.JavascriptReachability.enqueueResolved (13 samples)
- 1.25% com.codename1.tools.translator.IteratorEscape.walk (12 samples)
- 1.15% com.codename1.tools.translator.DeadFieldElimination.run (11 samples)
- 1.15% com.codename1.tools.translator.bytecodes.Invoke.findMethodUp (11 samples)
- 1.04% com.codename1.tools.translator.NativeSymbolIndex.<init> (10 samples)
- 1.04% java.io.FileOutputStream.open0 (10 samples)
- 1.04% java.lang.String.equals (10 samples)
- 1.04% com.codename1.tools.translator.BytecodeMethod.optimize (10 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 · 2026-10-28T08:36:11Z

Compared 206 screenshots: 206 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 50ms / native 3ms = 16.6x speedup
SIMD float-mul (64K x300)	java 48ms / native 3ms = 16.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	gated to scalar (CPU autovectorizes scalar; explicit SIMD not beneficial here)
Base64 CN1 encode	60.000 ms
Base64 CN1 decode	72.000 ms
Base64 SIMD encode	78.000 ms
Base64 encode ratio (SIMD/CN1)	1.300x (30.0% slower)
Base64 SIMD decode	73.000 ms
Base64 decode ratio (SIMD/CN1)	1.014x (1.4% slower)
Image encode benchmark iterations	100
Image createMask (SIMD off)	5.000 ms
Image createMask (SIMD on)	1.000 ms
Image createMask ratio (SIMD on/off)	0.200x (80.0% faster)
Image applyMask (SIMD off)	18.000 ms
Image applyMask (SIMD on)	18.000 ms
Image applyMask ratio (SIMD on/off)	1.000x (0.0% slower)
Image modifyAlpha (SIMD off)	22.000 ms
Image modifyAlpha (SIMD on)	12.000 ms
Image modifyAlpha ratio (SIMD on/off)	0.545x (45.5% faster)
Image modifyAlpha removeColor (SIMD off)	23.000 ms
Image modifyAlpha removeColor (SIMD on)	13.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off)	0.565x (43.5% 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.00x (base 1.11x, -9.8%)	0.63x (base 0.75x, -16.6%)	ok
translator (self)	4	0.84x (base 0.84x, +0.5%)	0.47x (base 0.51x, -6.8%)	ok
intArithmetic	4	1.04x (base 1.04x, -0.0%)	0.06x (base 0.06x, +3.1%)	ok
longArithmetic	4	0.80x (base 0.80x, +0.0%)	0.06x (base 0.06x, +3.4%)	ok
mathTranscendental	4	0.72x (base 0.72x, +0.1%)	0.07x (base 0.06x, +1.6%)	ok
arraySequential	4	0.39x (base 0.46x, -14.2%)	0.39x (base 0.39x, -0.0%)	ok
arrayRandom	4	0.94x (base 0.94x, +0.4%)	0.23x (base 0.23x, +0.2%)	ok
objectAllocation	4	1.79x (base 1.82x, -1.7%)	0.41x (base 0.43x, -3.7%)	ok
valueEscape	4	0.76x (base 0.76x, +0.1%)	0.05x (base 0.05x, +2.5%)	ok
hashMapChurn	4	1.00x (base 0.98x, +1.4%)	0.12x (base 0.12x, -1.0%)	ok
stringBuilding	4	1.60x (base 1.43x, +12.2%)	0.27x (base 0.27x, -0.1%)	ok
recursion	4	1.55x (base 1.46x, +6.0%)	0.07x (base 0.07x, +1.4%)	ok
quicksort	4	1.01x (base 1.00x, +0.5%)	0.12x (base 0.12x, +0.6%)	ok

Result: no regression

vm-tests: the lens reads through readCanvasPixels now (#6123)

cd85234

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

shai-almog merged commit e786092 into master Oct 28, 2026
119 checks passed

shai-almog deleted the js-no-display-readback branch October 28, 2026 08:28

Navigation Menu

Repository navigation

JavaScript port: never read the display canvas back (#6123) - #6124

JavaScript port: never read the display canvas back (#6123)#6124
shai-almog merged 3 commits into
masterfrom
js-no-display-readback

shai-almog commented Oct 28, 2026

Uh oh!

github-actions Bot commented Oct 28, 2026

Uh oh!

shai-almog commented Oct 28, 2026 •

edited

Loading

Uh oh!

shai-almog commented Oct 28, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Oct 28, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Oct 28, 2026 •

edited

Loading

Uh oh!

shai-almog commented Oct 28, 2026 •

edited

Loading

Uh oh!

shai-almog commented Oct 28, 2026 •

edited

Loading

Uh oh!

shai-almog commented Oct 28, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Oct 28, 2026

Uh oh!

Uh oh!

shai-almog commented Oct 28, 2026 •

edited

Loading

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

shai-almog commented Oct 28, 2026

Uh oh!

github-actions Bot commented Oct 28, 2026

Cloudflare Preview

Uh oh!

shai-almog commented Oct 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Benchmark Results

Detailed Performance Metrics

Uh oh!

shai-almog commented Oct 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Oct 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Oct 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Continuous Quality Report

Test & Coverage

Static Analysis

Uh oh!

shai-almog commented Oct 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Benchmark Results

Detailed Performance Metrics

ParparVM vs HotSpot (JDK 25): Windows x64

Uh oh!

shai-almog commented Oct 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

ParparVM vs HotSpot (JDK 25): Linux x64

Uh oh!

shai-almog commented Oct 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

ParparVM vs HotSpot (JDK 25): Linux arm64

Uh oh!

github-actions Bot commented Oct 28, 2026

✅ ByteCodeTranslator Quality Report

Test & Coverage

Benchmark Results

Static Analysis

Uh oh!

Uh oh!

shai-almog commented Oct 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Benchmark Results

Detailed Performance Metrics

ParparVM vs HotSpot (JDK 25): Windows arm64

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

shai-almog commented Oct 28, 2026 •

edited

Loading

shai-almog commented Oct 28, 2026 •

edited

Loading

github-actions Bot commented Oct 28, 2026 •

edited

Loading

github-actions Bot commented Oct 28, 2026 •

edited

Loading

shai-almog commented Oct 28, 2026 •

edited

Loading

shai-almog commented Oct 28, 2026 •

edited

Loading

shai-almog commented Oct 28, 2026 •

edited

Loading

shai-almog commented Oct 28, 2026 •

edited

Loading