Skip to content

fix: preserve hex color alpha precision - #1813

Closed
mmporong wants to merge 1 commit into
melonjs:masterfrom
mmporong:fix/hex-alpha-precision
Closed

mmporong wants to merge 1 commit into
melonjs:masterfrom
mmporong:fix/hex-alpha-precision

Conversation

@mmporong

Copy link
Copy Markdown
Contributor

Description

Hex colors with alpha were rounded to one decimal when parsed, so values such as #0000FF01 became fully transparent and most 8-bit alpha values could not round-trip. toHex8() also truncated float alpha values instead of rounding them to the nearest byte.

This change preserves the full alpha value from 4- and 8-digit hex colors and rounds alpha when serializing to #RRGGBBAA. Regression coverage checks every 8-bit alpha value, every 4-bit shorthand alpha, low alpha, and rgba() serialization.

Type of change

  • Bug fix
  • New feature
  • Documentation update
  • Performance improvement
  • Refactoring (no functional changes)

Checklist

  • I have read the Contributing Guide
  • My code follows the existing code style (pnpm lint passes)
  • I have tested my changes locally (pnpm test passes)
  • I have added tests that cover my changes (if applicable)
  • The build succeeds (pnpm build)

The focused Chromium suite passes all 126 color tests. The complete browser suite was not run locally.

Related issues

None.

obiot added a commit that referenced this pull request Nov 1, 2026
…idation (#1821)

Three fixes by @mmporong, from #1812, #1813 and #1814:

- Line#contains() checks the segment endpoints as well as collinearity; a point on the line beyond either endpoint was reported as contained
- Color#parseHex() keeps the exact alpha byte of #RRGGBBAA / #RGBA colours instead of rounding it to one decimal (#0000FF01 was fully transparent); toHex8() output is unchanged, and every hex alpha round-trips
- isPowerOfTwo() rejects zero, negative and fractional values, and is correct beyond the 32-bit range

Co-authored-by: mmporong <mmporong@gmail.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JnzwA4xBNBw7cEZzG1bUru

obiot commented Nov 1, 2026

Copy link
Copy Markdown
Member

Thank you, @mmporong! This fix is now on master via #1821, which brought in your three PRs together. Your commit went in as you wrote it, and you're credited as co-author on the merge commit and in the changelog.

One follow-up commit in #1821 keeps toHex8() exactly as it was, truncating instead of rounding. We wanted the fix to stay internal, and rounding would have changed what toHex8() returns for colours whose alpha isn't a whole byte (0.5 gives …7F; rounded it would give …80). Your parseHex() change is all the fix needs: with the exact byte / 255 stored, toHex8() already writes every 8-bit and 4-bit hex alpha back unchanged, and your round-trip tests pass as they are.

I'm closing this one since #1821 merged it. Thanks again, especially for the thorough round-trip tests.


Generated by Claude Code

@obiot obiot closed this Nov 1, 2026
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.

2 participants