Fix Hue wheel #351
Fix Hue wheel #351
Conversation
|
Deploying terrazzo with
|
| Latest commit: |
64d75ee
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://3495be79.terrazzo.pages.dev |
| Branch Preview URL: | https://fix-hue-wheel.terrazzo.pages.dev |
| @@ -1,4 +1,8 @@ | |||
| { | |||
| "extends": "./tsconfig.json", | |||
| "compilerOptions": { | |||
| "module": "NodeNext", | |||
| "moduleResolution": "nodenext" | |||
There was a problem hiding this comment.
This is a bug with the Rollup TS plugin I’m too lazy to fix right now—it doesn’t do a good job of tracing the extends to resolve the final TSConfig. This is redundant, but is easier than fixing the bug upstream.
| @@ -243,12 +227,12 @@ void main() { | |||
| // 3 = projection toward point, hue dependent | |||
| // 4 = adaptive Lightness, hue independent | |||
| // 5 = adaptive Lightness, hue dependent | |||
| int clamp_mode = 2; | |||
| int clamp_mode = 3; | |||
There was a problem hiding this comment.
There are quite a few changes in the WebGL code, but this was basically a fix—a one-liner. I was halfway to experimenting with some alternate methods of generating the hue wheel, but ultimately we should use the thing that looks best, and that’s changing the clamp method
| gl: WebGL2RenderingContext; | ||
| startColor: WebGLColor; | ||
| endColor: WebGLColor; | ||
| startColor: Oklab; |
There was a problem hiding this comment.
Another design problem of the WebGL code was trying to make it magically handle all color spaces, all gamuts. This is far too much responsibility for it, and also isn’t necessary since at any given time, we’re only operating in one colorspace!
Instead, if we simply restrict the WebGL code to operate in the Oklab space alone, we don’t lose any performance benefits. It does what it does best—performs crazy-fast translations between Oklab <> Linear RGB. And the only time we have to calculate colorspaces on the main thread in JS is just 2 times—start and end color, which is trivial. Keeping WebGL in Oklab still reaps all the benefits but sheds a ton of complexity and potential bugs.
| "react": "19.0.0-rc-cae764ce-20241025", | ||
| "react-dom": "19.0.0-rc-cae764ce-20241025", | ||
| "rollup": "^4.26.0", | ||
| "react": "19.0.0-rc.1", |
There was a problem hiding this comment.
RC gettin closer! 🎉
drwpow
force-pushed
the
fix-hue-wheel
branch
3 times, most recently
from
d966ad0
to
17b3c6e
Compare
| @@ -3,7 +3,7 @@ | |||
| "compilerOptions": { | |||
| "baseUrl": ".", | |||
| "module": "NodeNext", | |||
| "moduleResolution": "NodeNext", | |||
| "moduleResolution": "nodenext", | |||
There was a problem hiding this comment.
VS Code would consistently autocomplete to NodeNext before, but today it is consistently recommending nodenext. Stylistic change from TS itself? Dunno.
drwpow
force-pushed
the
fix-hue-wheel
branch
from
17b3c6e
to
64d75ee
Compare
| } | ||
| const leftColor = { ...color.original, [channel]: displayMin ?? min }; | ||
| const rightColor = { ...color.original, [channel]: displayMax ?? max }; | ||
| const leftOklab = useMemo(() => withAlpha(toOklab(leftColor) as Oklab) as Oklab, [color.css]); |
There was a problem hiding this comment.
The useColor() hook I made because I’M sO sMArT could be better, because adjustments like this are hard (specifically, this nonsense is because the original color may be in another space, so we want to adjust the color before converting, which isn’t currently possible.
I may just ditch it in favor of raw Culori methods, but for now this is a bandaid to not refactor that.
I’m honestly really happy with the performance of useColor as it’s designed to be used. My problem is I need more from its design 😓
Changes
Fixes Hue wheel. Caused by me playing around with something and forgetting about it. Fixes #336
Before
After
How to Review