Skip to content

Version 3.1.0

Choose a tag to compare

@thednp thednp released this 04 Aug 11:50
· 3 commits to master since this release

What changed

Added

  • A benchmark suite in test/dommatrix.bench.test.ts comparing the current implementation against a test/fixtures/index-3.0.x.ts snapshot of the previous release: a parity suite (every operation must produce output identical to the backup, within 1e-9) and a performance suite with interleaved, median-of-2 sampling per operation. Measurements are skipped automatically under coverage (istanbul instrumentation distorts timings); run pnpm bench.
  • A native comparison suite in test/native.bench.test.ts comparing the current implementation against the browser's native DOMMatrix: parity at 1e-9 for 21 operations plus interleaved performance measurements; run pnpm bench:native.
  • pnpm bench and pnpm bench:native scripts. Both suites store their result tables on globalThis.__CSSMATRIX_BENCH__ / __CSSMATRIX_NATIVE_BENCH__ for inspection in pnpm test-ui devtools, and print a combined table to the terminal (browser console.table output is not forwarded by Vitest).

Changed

  • Major performance rework of the internal hot paths, all parity-verified against the previous release and against native DOMMatrix:
    • new CSSMatrix(init) now fast-paths string / array / typed-array / object initializers instead of round-tripping through setMatrixValue(), and construction is funneled through a new internal fromValues() factory that writes all 22 aliases in one pass (a single hidden class keeps the constructor monomorphic).
    • CSSMatrix.fromString() parses transform lists with a single regex iteration instead of split/filter/forEach, with equivalent strict validation of non-transform garbage.
    • CSSMatrix.fromArray() and CSSMatrix.fromMatrix() validate and destructure input directly, no intermediate Array copy.
    • multiply()/multiplySelf() share a new multiplyInto() kernel with a single 64-multiplication pass; multiplySelf() writes into this instead of allocating and spreading a result object.
    • translate(), translateSelf(), scale(), scaleSelf(), skew(), skewSelf() (plus skewX()/skewY() delegating to skew()) use specialized pre-multiply math instead of general matrix multiplication.
    • toJSON() builds the result object with explicit property writes instead of spreading this; toFloat32Array()/toFloat64Array() build typed arrays directly, skipping the intermediate toArray() allocation.
  • Measured performance deltas (vs 3.0.7 snapshot, Chromium, pnpm bench; ops/s ratios are noise-floor-corrected via interleaved sampling): multiplySelf ~17–18x, scale ~13x, skew ~6–14x, translate ~6.5–13x, multiply ~7x, fromMatrix ~7–7.6x, rotate ~5–5.6x, rotateAxisAngle ~4.1–4.5x, toJSON ~9.7–10.1x, new CSSMatrix(transform list) ~1.9–2.4x; unchanged code paths (new CSSMatrix(), fromArray, transformPoint, toString, is2D/isIdentity) measure ~0.96–1.1x.
  • vs native DOMMatrix (pnpm bench:native, Chromium): the shim is faster on construction and mutation-heavy operations (e.g. multiplySelf ~48x, translateSelf ~28x, scaleSelf ~36x, multiply ~4x — largely native's Web IDL per-property access and toJSON() overhead), while native wins the pure-compute cases: transformPoint ~0.36x and toString ~0.84x (shim/native ratios); toFloat32Array is at parity.

Fixed

  • CSSMatrix.toArray() remained coverage-uncovered after the typed-array paths stopped using it; the is2D branch is now exercised by tests again (coverage back to 100%).

Full Changelog: 3.0.6...3.1.0