Rezmason / matrix

matrix (web-based green code rain, made with love)
https://rezmason.github.io/matrix
MIT License
3.29k stars 212 forks source link

Reimplement MSDF logic based on chlumsky's examples to avoid issue seen in SwiftShader #24

Closed briantully closed 1 year ago

briantully commented 1 year ago

This is amazing work! At first I thought it wasn't working on my M1 Pro Macbook, but I realized it was due to Google Chrome. It looks great in Firefox and Safari, but for some reason the gradient streams do not appear within the glyphs themselves and instead appear as solid columns of green. I checked the docs and the issues to see if there was a known issue with Google Chrome but couldn't find any, so I'm posting this issue. I've attached a screenshot of what I see with Google Chrome (stable and beta versions), which occurs on several Macs.

Matrix digital rain-2022-09-26-000022

Rezmason commented 1 year ago

Thanks for your kind words!

Will you please try appending ?renderer=regl to the URL, and let me know if that makes it appear as expected? If so, then there may be an issue in my WebGPU code, or in Chrome's almost-done WebGPU support.

Rezmason commented 1 year ago

I've switched the default renderer back to regl, as I'm investigating some discrepancies between the renders of the two codebases.

briantully commented 1 year ago

Hi there! I've tried adding the query string, e.g., https://rezmason.github.io/matrix/?renderer=regl but it still shows the same for me in Google Chrome. Any other query strings you'd like me to try?

Rezmason commented 1 year ago

Shoot, that rules out WebGPU entirely!

My next theory is that the issue is specific to MSDF rendering— the technique for drawing crisp symbols. Can you compare these websites across your browsers? Do any have the same issue (or any issue, really) in Chrome on your machine?

https://openglobus.org/examples/fonts/fonts.html

https://observablehq.com/@stwind/msdf-text-label (the text on the corners of the cube)

https://monkin.github.io/webgl-dsl/examples/build/roboto.html

briantully commented 1 year ago

Shoot, that rules out WebGPU entirely!

My next theory is that the issue is specific to MSDF rendering— the technique for drawing crisp symbols. Can you compare these websites across your browsers? Do any have the same issue (or any issue, really) in Chrome on your machine?

https://openglobus.org/examples/fonts/fonts.html

These look identical in Chrome and Firefox

https://observablehq.com/@stwind/msdf-text-label (the text on the corners of the cube)

There isn't a difference in the text per se, but note that there is a difference in the cube's shading, where Chrome fills it in with a dark grey whereas Firefox keeps the cube transparent. Screenshot below:

MSDF Text Labels  Zihou Ng  Observable-2022-09-26-000038

https://monkin.github.io/webgl-dsl/examples/build/roboto.html

These look identical in Chrome and Firefox

Rezmason commented 1 year ago

That one screenshot teases that something is rotten in the state of Denmark— but I fear I won't have much luck fixing this issue without an M1 Mac at my disposal.

I might ask some coworkers to help me isolate the issue after hours, or something, but it may be a while before this bug is fixed. 🙁

briantully commented 1 year ago

Great catch on thinking it might be M1 related. As a test I tried loading the Classic Matrix code on my Intel Mac Pro using Google Chrome, and indeed it works as expected. So it might very well be a Google Chrome + M1 issue. Thanks again for the awesome work!

DustinBrett commented 1 year ago

I had this same issue occur for me just now on my Lenovo Windows 10 laptop. I was using the webgl renderer. My GPU is Intel Iris Xe Graphics. On my PC, also Windows 10, it works, and that cube is just lines. But on my laptop it's fully grey.

image

Rezmason commented 1 year ago

As a test I tried loading the Classic Matrix code on my Intel Mac Pro using Google Chrome, and indeed it works as expected.

I had this same issue occur for me just now on my Lenovo Windows 10 laptop

I appreciate you both making the time to test that for me and share what you found!

This may provide enough rationale to attempt a fallback step in the shader that avoids what I think is messing up— though detecting the bug from within the software is an interesting challenge. I'll revisit this issue when I have some hardware I can repro it on.

luciodaou commented 1 year ago

I have the exact same issue on Edge in Windows 10 running on an i5-3570. On Firefox it's perfect.

arnfiix commented 1 year ago

I am seeing the same thing in Chrome on Win 10. Running it in Firefox and it renders correctly.

EDIT: Just had a poke in the Chrome settings and noticed that I had hardware acceleration disabled. Enabled this and now it renders perfectly.

Rezmason commented 1 year ago

I had hardware acceleration disabled. Enabled this and now it renders perfectly.

Thanks, that's something folks should check.

I had another thought, which I'll also test out— maybe the WebGL extension I'm relying on isn't enabling on these devices. I'll push a change that'll make this easy to test without breaking anything.

Rezmason commented 1 year ago

I'm not confident in these potential fixes, but at least now there's a way to test them in the wild.

Do either of these fix these issues for anyone?

https://rezmason.github.io/matrix/?testFix=fwidth_10_1_2022_A https://rezmason.github.io/matrix/?testFix=fwidth_10_1_2022_B

Edit: wrote the wrong URLs

DustinBrett commented 1 year ago

I got good and bad news. I went to try those links and they looked good. Then I tried the old example that didn't work and that also was working on my laptop now. To test I turned off hardware acceleration in Chrome and it then again looked bad. And these 2 new links also looked bad/broken without hardware acceleration. I don't know how I got my laptop in a state where it was off before, but after turning it back on it seems fine now. Ideally though I'd rather the animation stay consistent even without hardware acceleration.

briantully commented 1 year ago

EDIT: Just had a poke in the Chrome settings and noticed that I had hardware acceleration disabled. Enabled this and now it renders perfectly.

Wow, great catch @arnfiix ! On all my Chrome browsers I too had hardware acceleration disabled. I enabled it and now the Matrix code renders as it should. I can't remember if I manually disabled hardware acceleration for performance reasons or if it is disabled by default. Anyway, it now works great.

I guess this can be closed now? Perhaps there just needs to be a note in the README stating that hardware acceleration needs to be enabled in order for it to work in Google Chrome.

What's interesting is that if I disable hardware acceleration in Firefox the Matrix code still renders correctly (even after a restart).

Rezmason commented 1 year ago

Flipped the switch you mentioned in Chrome Canary, and,

image

Eyyy, that's a repro! ...I'm utterly baffled.

"Hardware acceleration" conventionally means "uses the GPU", which is 100% what this effect does, it's all GPU all the time 😃. Reading your observations, I thought maybe Chrome was compositing your browser windows back on the CPU or something. But based on how slow this is running, I think maybe Chrome with hardware acceleration disabled, uh... emulates a GPU on the CPU? Would they do that?!

I'll update the readme with a note about this, and maybe try and detect it from the code, but I'll also try and research Chrome's "hardware acceleration", and maybe reach out to some Chrome folks. Meanwhile, I'll rename this ticket and link to it in those conversations. What a roller coaster this one is!

Rezmason commented 1 year ago

image

Part 1 is done: we're now detecting Chrome's software renderer fallback, which I still can't quite believe exists, and presenting players with a choice: run the effect slowly through SwiftShader, or turn on their hardware acceleration.

Part 2 is, honestly, the thing going wrong in SwiftShader is unnecessary and in the process of being removed.

briantully commented 1 year ago

Now THAT is how you do an awesome notification dialog! Amazing 🙏☺️

Rezmason commented 1 year ago

Turns out we substantially benefit from fwidth after all, at least for now, because the paradise version performs a polar transform on the full screen quad's UV coordinates, et cetera.

Instead, I've revisited chlumsky's original MSDF documentation and realized I might just be doing the math totally wrong.

The corrected algorithm now renders glyphs properly at the breakneck speed of 4 FPS in Chrome's software renderer.

Let me know if it's still broken. What a fun way to meet people.

DustinBrett commented 1 year ago

Thanks, this looks good without HW acceleration on Chrome now! For me it actually looks as smooth as with HW acceleration, but I have decent CPU so maybe that helps. I'd like to use this new version on my website but is it possible for the fallback to not have that blue/red pill question, as I would only want it in a fallback situation in which perhaps the user has no hardware acceleration or it's off for some reason where they won't turn it on. Thanks again!

Running in SW mode image

DustinBrett commented 1 year ago

Actually I see the code for isRunningSwiftShader() so I can figure this out. Thanks again!

JamesDBartlett3 commented 1 year ago

@Rezmason I have a machine that has no hardware acceleration of any kind, so I always get the bluepill/redpill greeting when I load the page, regardless of browser settings. Is there any way that I can bypass the SwiftShader dialog, perhaps with a URL parameter?

Rezmason commented 1 year ago

I should have thought of that. I'll see what I can do.

Rezmason commented 1 year ago

All right @JamesDBartlett3 try adding suppressWarnings=true to the URL. Also, from now on, clicking the "PLUG ME IN" button in the notice appends that parameter to the URL.

JamesDBartlett3 commented 1 year ago

@Rezmason That's the fastest turnaround time on a new feature suggestion I've ever seen! Fantastic, thank you so much!