xterm.js
xterm.js copied to clipboard
xtermjs
Different foreground color in dom vs webgl when using min contrast ratio
The top color's contrast is 4.41:1 which is less than 4.5 🐛 Bottom's is 4.85:1 ✔️
Having trouble reproducing this, chances are this is the problem code:
https://github.com/xtermjs/xterm.js/blob/c0215711946634f32f1946f6a890fd948c1f0068/src/browser/renderer/dom/DomRendererRowFactory.ts#L279-L284
Pushing out as this isn't too important.
Cannot repro either - I get the same color values on DOM,canvas and webgl (tested several colors).
I wonder if we should introduce explicit renderer output API tests to test for output differences (had the same "geez, renderer xy bahaves differently here" issue in the weblinks PR). But this is quite hard to get running - would need DOM/canvas/webgl test instances, and a good story, how to grab the data points in questions for eval. The latter is really hard to achieve, as its often just some unwanted tiny pixel output differences - no clue how to eval that w'o pulling very sophisticated image analysis tools into the toolchain. Maybe its not worth it... :sweat_smile:
The webgl api tests aren't actually that far off, at least to adapt to test the canvas renderer. As for DOM, we could potentially reuse them by capturing a screenshot of the page. Pretty sure web can take actual screenshots of the whole display now with user permission which we could tell playwright to use.
Also the only reason the webgl api tests are stable is because we use a block element character to test colors, my experience with pixel tests is that it's not worth trying to compare pixels as they differ between hardware.
Ah yeah - the "big fat block" idea would at least make comparable coloring tests possible.
Idk how far off webgl to canvas can get from hardware differences, at least on my machine switching them does not change the output state in a perceivable manner (just checked it with ls output and the custom glyph output of the demo, so this is not an exhaustive test at all). I'd still expect some tiny differences, esp. at subpixel/anti-alias handling, which still would make pixelwise comparison faulty. (Thats one reason, why canvas fingerprinting has a high chance to uncover your real GPU hardware.)
And the DOM - well it does DOM things (dumb things?), getting that comparable def. needs some image analysis heuristics. Geez...
Idk how far off webgl to canvas can get from hardware differences, at least on my machine switching them does not change the output state in a perceivable manner
I think the only difference now after texture atlas sharing is just canvas cannot draw the glyph beyond the line, but webgl can.