-
-
Notifications
You must be signed in to change notification settings - Fork 800
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
graphics aren't entirely cleared when redrawn with transparent elements #1063
Comments
i mean, i guess it must have been introduced since WezTerm introduced graphic transparency (thanks again!), so there's that. also, to make clear: i wouldn't have filed this at all, except that things are working perfectly in all other emulators i've tried. that doesn't mean it's definitely a WezTerm problem, of course, but it does IMHO justify filing the issue. i'll continue researching. |
Thanks for opening this here. I don't have any immediate flash of insight into what's happening, but here's some background in case it helps you point a finger more squarely in some direction... Wezterm places cell quads in row major order, placing the glyph quad first, then if there's an image attachment with z >= 0, that goes over the top of that cell. If the background color for cells in the "frames per" row in the image are not the default terminal background color, I'd expect that color to paint over the bottom of the orca if the previous row escaped the bounds of the cell. Since that doesn't appear to be happening, that leads me to believe that the "frame per" row has image attachments associated with it. I wonder if there is a difference in opinion/math between how wezterm decides to slice the image across the terminal cells and what notcurses expects to happen? That logic is here in this function that wezterm uses for all three image protocols: https://github.com/wez/wezterm/blob/main/term/src/terminalstate/image.rs#L61 You can enable this log line https://github.com/wez/wezterm/blob/main/term/src/terminalstate/image.rs#L97 and see what wezterm is computing if you start wezterm like this:
|
i'll run this immediately |
some raw output:
|
datum: close manual inspection suggests that there are 7 extra rows of pixels in this example |
alright, i have 55 rows, 0 -- 54. the orca does not use the bottom row. it ought not be visible in the bottom 6 rows, 49--54. she starts on 34's origin and has 515 pixels. at 25 per, that's 20.6 rows. so 34--53. that checks out with not occupying the bottom row. she is only partially (3/5) occupying row 53. having been cut out of the bottom 6, she should actually only be 34--48, i.e. 15 rows i.e. 375 pixel rows. now let's see what the logs say... |
|
part in parens is just our screen + cell geometry |
let me check the encoded output using Kitty+animation. there we ought be placing our animated output precisely. so if there is anything below ... she starts at pixel row 850. 375 pixel rows means she goes through 1224 (of 1375), leaving 150 empty, which checks out with the fact that she's excluded from the bottom 6. the offending pixel rows are thus 1225..1231. there we have orcaflesh where we oughtn't. whose fault? |
hrmmmmmmmmm!!!
|
confirmed that z=0 does not get cleared by emission of text, so if i simply wasn't emitting the wipe at 375, we'd still expect to see a full cell's worth of pixels there... |
FWIW, the y values printed above are 0-based, starting from the top of the viewport
Not sure if you're 1-based or 0-based here; feels like something is off by one row compared to the log lines above? (0-based 33 to 53 inclusive).
Those deltas are texture coordinate offsets being assigned to the cells; the overall bitmap being sliced across the cells has texture coordinates ranging from 0.0 for the left/top through to 1.0 for the right/bottom. Those delta values are added to the texture coordinates that are recorded on each cell as the loops advance. x_delta * width_in_cells should equal 1.0 and similarly for y_delta.
The consequence of these being wonky would be the graphics being scaled a bit weird within their respective cells, rather than overflowing them, as the texture coordinate is passed through to opengl when it texture maps the quad, and the quad's position is the cell boundaries. Not sure what conclusions to draw from this right now; need to come back to this when I'm not so tired! |
you are correct, thanks. 34--53 is only 20 rows, and i'm occupying 20.6; i'm in 33--53. |
so between the demonstration above that it's definitely the graphic that's being overdrawn/undererased, and the demonstration that i'm erasing correctly over in dankamongmen/notcurses#2076, the fact that it works in kitty, and the fact that it's broken in the same way in wezterm-sixel and wezterm-kitty, my conscience is feeling pretty clear. i'm happy to assist in any way i can, and don't expect this to be a high-priority fix for you or anything, but i see no indication that this is a notcurses bug, and every indication that it is not. heh sorry if that sounded dick; i didn't mean it to. i'm just saying i don't have much more to push on here, and doubt this to be the kind of easy fix that i could just knock out in wezterm, so i'm leaving this in your capable hands. <3 |
oooh it looks like this might have been fixed?!! let me make sure....also it's possibly a cell-pixel geometry thing? what did i have here? i'm seeing good behavior from 25x11...yep, that's what i had before! well hot damn! @wez did you do something that you can imagine having fixed this? |
i'm seeing good behavior on 20210922-215454-b19162b9 |
Oh, that's a surprise! I'm not totally sure what might have directly influenced this. A couple of possibly related commits: 0ee1f75 - fixed getting inaccurate advances for glyphs during shaping (feels too late in the render process to affect what you see in the terminal model though) |
Yes please; let's have a separate issue for that one, thanks! |
e287474 is actually the change I thought of first while reading your comment, but it is newer than the build you mentioned, and would only impact you if you're using a bitmap font. |
well, i'm unsure what happened, but even testing with my older code, the problem seems resolved on current wezterm using the same geometries. so i'm calling this happily resolved. i'll get info on the other issue i'm seeing (much more rarely) and create a new bug. |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
What Operating System(s) are you seeing this problem on?
Linux X11
WezTerm version
wezterm 20210819-212236-f845df81
Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?
Yes, and I updated the version box above to show the version of the nightly that I tried
Describe the bug
Unfortunately, I do not yet have a clear and concise summation of the bug, which is described at some length here: dankamongmen/notcurses#2076. I've done some initial investigation that IMHO points blame away from my client program, but I have not yet been able to produce a minimum example. Furthermore, I am surprised and confused that this happens in all drawing modes (I've tested with Sixel, Kitty not using animation, and Kitty using animation). This latter definitely suggests that my client code is the culprit. So take this with a grain of salt.
As you can see in the link above, the
intro
cycle fromnotcurses-demo
has some small issues on WezTerm. I can't say with certainty that this is a regression as opposed to a longstanding problem, and I'm happy to bisect if you think it might have been introduced recently. Essentially, initial drawing of a graphic has no problems. Later, I'm moving that graphic (this makes sense in kitty; in Sixel, "moving" means "i wrote glyphs over the old areas, and drew the graphic anew") horizontally across the screen from right to left. As I do so, the graphic encounters some blocking text, and thus I "wipe" the bottom of the graphic away. In sixel, this means supplying no pixel for the affected regions. In Kitty, this means supplying all-null-alpha regions. In WezTerm, this is leading to a few rows' worth of "bleed", where the original pixels are still visible. Here's an example:note the two areas circled in green. in both of these places, elements of the old image are visible where they oughtn't be.
Now, the fact that this happens in all three drawing modes points to my bug, I agree. I have only done a deep inspection of the encoded output for the Kitty-without-animation case, but I verified there (see linked bug) that:
a=p
arguments), anduniq
)which seems to pretty clearly point away from there being data i didn't intend.
sooooooooooooooooooooooo i'm just filing this to make sure you're aware. if you have any insights that you want to check, you can do that, though i still consider the ball to be in my court until i have a minimum example. i'm going to work on getting one of those. in the meantime, this is hardly the worst possible problem one could have, so don't stress about it.
To Reproduce
Run the
notcurses-demo
i
ntro cycle. If you'd like to be able to inspect it closely, I recommend scaling artificial delays by 10x and running the cycle several times ala:./notcurses-demo -p ../data -d10 iiiiii
My usual WezTerm geometry is
55 rows (25px) 99 cols (11px) 1375x1089
but this problem has been seen on a variety of geometries.
Configuration
Expected Behavior
The graphic ought be cleanly cut off at cell boundaries. Instead, several (but not all) rows of pixels are leaking into the top occluding row of cells.
Logs
2021-08-21T22:01:01.844Z INFO wezterm_mux_server_impl::local > setting up /run/user/1000/wezterm/gui-sock-1697155
2021-08-21T22:01:01.938Z INFO wezterm_gui::termwindow > OpenGL initialized! NVIDIA GeForce RTX 2070 SUPER/PCIe/SSE2 4.6.0 NVIDIA 470.57.02 is_context_loss_possible=false wezterm version: 20210819-212236-f845df81
2021-08-21T22:01:07.920Z INFO wezterm_gui::frontend > Ding! (this is the bell)
2021-08-21T22:01:09.076Z INFO wezterm_gui::frontend > Ding! (this is the bell)
2021-08-21T22:01:10.018Z INFO wezterm_gui::frontend > Ding! (this is the bell)
2021-08-21T22:01:12.091Z INFO wezterm_gui::frontend > Ding! (this is the bell)
2021-08-21T22:01:27.331Z WARN wezterm_term::terminalstate::performer > unknown unspecified CSI: ">1s"
Anything else?
No response
The text was updated successfully, but these errors were encountered: