CRT curvature fill in is white after "Improve terminal frame and expose frame size setting." #739

Open
opened 2022-07-19 02:54:52 +02:00 by ali1234 · 11 comments
ali1234 commented 2022-07-19 02:54:52 +02:00 (Migrated from github.com)

Screenshot @ 3104abd4ad:
image

Screenshot @ 4abbe332db:
image

This is with the frame size set to zero. Also note the reflected text at the top left.

Screenshot @ 3104abd4ad7: ![image](https://user-images.githubusercontent.com/651970/179640763-f7c2bafc-80a6-4837-91c9-33fa82cf6b3e.png) Screenshot @ 4abbe332db25b70: ![image](https://user-images.githubusercontent.com/651970/179640937-0e8d81ae-0ac5-4de0-a9ca-8b0edbe6be60.png) This is with the frame size set to zero. Also note the reflected text at the top left.
Ashdemai commented 2022-07-19 15:56:10 +02:00 (Migrated from github.com)

This is a repeat of #703

Is there anything that can be done to fix this issue?

This is a repeat of #703 Is there anything that can be done to fix this issue?
ali1234 commented 2022-07-19 16:28:12 +02:00 (Migrated from github.com)

If this is a nvidia-only issue as claimed on that issue, then it could be due to an uninitialized buffer. I forget where I saw it, but the other drivers will zero new buffers by default. Technically GL doesn't require that, so nvidia doesn't do it.

If this is a nvidia-only issue as claimed on that issue, then it could be due to an uninitialized buffer. I forget where I saw it, but the other drivers will zero new buffers by default. Technically GL doesn't require that, so nvidia doesn't do it.
ali1234 commented 2022-07-20 03:28:27 +02:00 (Migrated from github.com)

After going through the shader code it seems the problem is with the positiveLog helper function: 4abbe332db (diff-cd3590184ef3de51987420ae526e23d1cbe53a6a353ceb217cd82b763120f1eeR75-R77)

The frameColour is multiplied by the value it returns. The maximum value is 100.0, which is far too big and blows out whatever colour the frame was supposed to be, making it effectively full white all the time. Changing it to values like 2.0, 5.0, 10.0 etc results in the frame corners looking darker than the rest, like this: (note I have made the background green so i can easier see what is going on)

image

Changing the maximum value to 1.0 makes the frame look okay but makes the shadow look weird:
image

Clamping the result only for the frame results in this:
image

This last one looks the most reasonable to me, but I am not sure what it really supposed to look like. Also, I don't yet understand why this would only affect Nvidia drivers.

After going through the shader code it seems the problem is with the positiveLog helper function: https://github.com/Swordfish90/cool-retro-term/commit/4abbe332db25b70fce5b9994be3f6ec3982107ad#diff-cd3590184ef3de51987420ae526e23d1cbe53a6a353ceb217cd82b763120f1eeR75-R77 The frameColour is multiplied by the value it returns. The maximum value is 100.0, which is far too big and blows out whatever colour the frame was supposed to be, making it effectively full white all the time. Changing it to values like 2.0, 5.0, 10.0 etc results in the frame corners looking darker than the rest, like this: (note I have made the background green so i can easier see what is going on) ![image](https://user-images.githubusercontent.com/651970/179875294-2c303322-8978-4ea9-a8bb-1c66cc9244c5.png) Changing the maximum value to 1.0 makes the frame look okay but makes the shadow look weird: ![image](https://user-images.githubusercontent.com/651970/179875738-dcd4f808-cff4-4f0f-a4ee-679b35237c36.png) Clamping the result only for the frame results in this: ![image](https://user-images.githubusercontent.com/651970/179875629-e20fe6b8-f54f-422d-9e0c-e9637e0a69e5.png) This last one looks the most reasonable to me, but I am not sure what it really supposed to look like. Also, I don't yet understand why this would only affect Nvidia drivers.
ali1234 commented 2022-07-20 03:33:37 +02:00 (Migrated from github.com)

Another possible fix is to just revert the change from using clamp to max for the frame: 4abbe332db (diff-cd3590184ef3de51987420ae526e23d1cbe53a6a353ceb217cd82b763120f1eeR90)

This produces a similar result, but the frame and shadow are slightly lighter:

image

Another possible fix is to just revert the change from using clamp to max for the frame: https://github.com/Swordfish90/cool-retro-term/commit/4abbe332db25b70fce5b9994be3f6ec3982107ad#diff-cd3590184ef3de51987420ae526e23d1cbe53a6a353ceb217cd82b763120f1eeR90 This produces a similar result, but the frame and shadow are slightly lighter: ![image](https://user-images.githubusercontent.com/651970/179876317-fbced13d-5ae3-41d0-ac05-a1474c85b6d8.png)
jlederman commented 2022-07-26 20:07:04 +02:00 (Migrated from github.com)

I'm confirming this bug exists on Debian 11 with the latest nvidia drivers.

Also confirming that changes suggested by @ali1234 look good, except for the frame shadow as noted. Changing the max value compared in the positiveLog function from 100 to 1 fixes the screen curvature appearing opaque white, but also makes the frame shadow appear way too big. I'm comparing to the demo screenshots in the readme.

I'm confirming this bug exists on Debian 11 with the latest nvidia drivers. Also confirming that changes suggested by @ali1234 look good, except for the frame shadow as noted. Changing the max value compared in the `positiveLog` function from `100` to `1` fixes the screen curvature appearing opaque white, but also makes the frame shadow appear way too big. I'm comparing to the demo screenshots in the readme.
RassilonSleeps commented 2022-08-05 01:01:53 +02:00 (Migrated from github.com)

Can also confirm bug is present on arch when run with nvidia drivers.
kernel: 5.18.16-zen
nvidia-dkms: 515.65.01-1

crt

Can also confirm bug is present on arch when run with nvidia drivers. kernel: 5.18.16-zen nvidia-dkms: 515.65.01-1 ![crt](https://user-images.githubusercontent.com/64247429/182969144-0dcfdbe9-1fc9-44af-a8d7-21343c218b5e.png)
The-Toblin commented 2022-10-28 09:36:09 +02:00 (Migrated from github.com)

Chiming in here.
Archlinux
kernel: 6.0.5-zen1-1-zen
nvidia-dkms: 520.56.06-2
crt: 1.2.0-2

(Don't have an old version to show it off working, sorry)
crt

Chiming in here. Archlinux kernel: 6.0.5-zen1-1-zen nvidia-dkms: 520.56.06-2 crt: 1.2.0-2 (Don't have an old version to show it off working, sorry) ![crt](https://user-images.githubusercontent.com/79937532/198530796-bee0832c-b88f-4248-a832-5a440981a014.jpg)
WhiskeyTuesday commented 2022-12-13 06:53:48 +01:00 (Migrated from github.com)

Can confirm that changing L90 of app/qml/TerminalFrame.qml from frameShadow = max(sqrt(frameShadow), 0.0); to frameShadow = clamp(sqrt(frameShadow), 0.0, 1.0); and recompiling is a "good enough for now" fix for anyone who wants one.

Can confirm that changing L90 of `app/qml/TerminalFrame.qml` from `frameShadow = max(sqrt(frameShadow), 0.0);` to `frameShadow = clamp(sqrt(frameShadow), 0.0, 1.0);` and recompiling is a "good enough for now" fix for anyone who wants one.
spencershoe commented 2023-02-16 21:59:35 +01:00 (Migrated from github.com)

this issue is now 7 months old, and last commit was a year ago according to github, is this project no longer maintained? based on the "solution" proposed by WhiskeyTuesday it doesn't appear to be that complicated of a fix.

this issue is now 7 months old, and last commit was a year ago according to github, is this project no longer maintained? based on the "solution" proposed by WhiskeyTuesday it doesn't appear to be that complicated of a fix.
pagesix1536 commented 2023-05-25 21:14:09 +02:00 (Migrated from github.com)

this issue is now 7 months old, and last commit was a year ago according to github, is this project no longer maintained? based on the "solution" proposed by WhiskeyTuesday it doesn't appear to be that complicated of a fix.

Seems like it's a great time to fork this project and work on it separately while this one is just left to die a slow death.

> this issue is now 7 months old, and last commit was a year ago according to github, is this project no longer maintained? based on the "solution" proposed by WhiskeyTuesday it doesn't appear to be that complicated of a fix. Seems like it's a great time to fork this project and work on it separately while this one is just left to die a slow death.
The-Toblin commented 2023-05-25 21:19:00 +02:00 (Migrated from github.com)

Tbh, I stopped using the program long ago. It's a fancy idea, but with the bugs and excessive system resource use...who cares?

Tbh, I stopped using the program long ago. It's a fancy idea, but with the bugs and excessive system resource use...who cares?
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: seeseemelk/cool-retro-term#739
No description provided.