Skip to content
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

Visual gaps in the window, near the edges of the content box #741

Closed
davegregg opened this issue Jul 24, 2018 · 15 comments
Closed

Visual gaps in the window, near the edges of the content box #741

davegregg opened this issue Jul 24, 2018 · 15 comments

Comments

@davegregg
Copy link

I'm seeing completely transparent gaps which variously appear and disappear on resize. See screenshot.

Here's another screenshot, with a second effect. You'll notice at the bottom that the line changes from full transparency to a blue color, then the line disappears and reappears, again blue.

Here is a screenshot of the effect with border, margin, and padding settings commented out.

Here is an example where the line wraps around from top, to left, to bottom (margin, border, and padding commented out).

Sometimes the line can be quite short, like an underscore.

Here is an unusual example.

I can repeat the effect by resizing the window randomly. The effect manifests as often as not.

Changing background_opacity to 1 and disabling dynamic_background_opacity has no effect. Tweaks to margin, padding, and border settings does not stop the problenm. Neither sync_to_monitor nor repaint_delay seem to have an effect on the bug.

@kovidgoyal
Copy link
Owner

That's weird. The gap does not extend the full length of the border? What OS is this and what version of kitty?

@kovidgoyal
Copy link
Owner

And what happens if you display multiplesub-windows in the same kitty window? Do the gaps appear next to each sub-window's content box?

@davegregg
Copy link
Author

Mac OS Mojave 10.14 Beta (18A336e)
Kitty 0.11.3

As you can see in this screenshot, any window of the same size appears to have the same "look" to the effect. But a differently-sized window will have a different appearance.

I have also just confirmed that if the current window has this effect when I close Kitty, and if I have it set to open a window of the exact same size next time Kitty starts, then the next time I start Kitty, it will in fact show the bug and it will exactly like it did the last time I ran Kitty.

I don't know what you mean by "multiplesub-windows in the same kitty window".

@davegregg
Copy link
Author

davegregg commented Jul 24, 2018

I think it's a bug with kitty icat. I have kitty icat displaying an image (which you can see) in my ~/.bash_profile file. Whenever I comment out the line which executes kitty icat, then the artifact doesn't appear.

@kovidgoyal
Copy link
Owner

Multiple windows means multiple kittywindows inside one top level window. See https://sw.kovidgoyal.net/kitty/#tabs-and-windows

If it is related to displaying an image then post the image and the relevant bits of your .bashrc

@kovidgoyal
Copy link
Owner

no followup

@davegregg
Copy link
Author

I didn't previously know about the multiple kittywindows feature, but here is a GIF recording of what I'm seeing, how it interacts with multiple kittywindows, how it interacts with resizing, and also something I had not noticed before: that the glitches blink with the cursor.

@davegregg
Copy link
Author

For the record, I should tell you that when you closed this ticket within 24 hours of my last comment (and of your clarification of what "kittywindows" means), I lost all interest in helping you debug your application out of frustration. This is why I haven't responded in all this time.

On hindsight, I realized that you might be following some ticket-management policy. But I don't see a bug-reporting or contribution policy listed anywhere.

This also means I don't know whether commenting on this issue is sufficient to get to reopened, or if I need to open a new ticket in order to get visibility.

@kovidgoyal
Copy link
Owner

kovidgoyal commented Aug 7, 2018

You still haven't bothered to post the information I asked for, namely your bashrc and whatever image you are displaying to cause the issue. If you do and if I can reproduce the issue it will get fixed, dont get hung up on the open or closed state of bug reports. I have a zero bugs policy for kitty (and all my software projects, more generally). Every bug report that I can reproduce, or that I can understand the cause of, if I cannot reproduce, gets fixed, immediately, or closed as wontfix if something makes fixing it not practical.

@davegregg
Copy link
Author

If it is related to displaying an image then post the image and the relevant bits of your .bashrc

Oh, sorry. I missed that sentence. Anyway, I think I have ruled these two vectors out (I will explain below). And I have a few other observations:

  1. I have tried many images, of varying formats and sources (some my own, some from the internet). It makes no difference.
  2. I currently have my ~/.bash_profile 100% commented out. I don't have ~/.profile, and my ~/.bashrc is blank. No effect.
  3. I do however have a single conditional in /etc/profile (without which kitty icat can't find ImageMagick):
if [ -x /usr/libexec/path_helper ]; then
        eval `/usr/libexec/path_helper -s`
fi
  1. Changing the font and restarting Kitty (I exclusively use monospace fonts) does change the position and length of the artifacts, even when the window size and position remain constant. I have tried this with native Mac OS fonts, such as Courier, as well as popular non-native terminal fonts.
  2. I tried to rule out ImageMagick. I was able to get pxl installed -- no glitches. I couldn't get w3m to display images in kitty, though I think it would have been a better test than pxl.
  3. In addition to the transparent lines, I have very rarely seen a line along the bottom edge of the window which looks like a single-pixel slice of a particular part of the window (I could see colors which were uniquely present in the prompt or image). I seen this a few times, but I have been unable to determine steps to reproduce the effect.

@kovidgoyal
Copy link
Owner

I need some way to reproduce the issue. If you say that it happens without any custom bashrc then something must be customized somewhere since many thousands of kitty users on macOS have never reported this issue. So what is different about your config? And why do you think it has anything to do with icat since you said that it happens even with no bash config? If it does not have anything to do with icat, then there can be no involvement of ImageMagick, since icat is the only thing in kitty that uses ImageMagick. So I suggest you do the followoing:

  1. Start with empty bash config and empty kitty.conf
  2. See if the problem reproduces, if yes goto (4)
  3. Add bits of kitty.conf/bashrc back piece by pices until you find a minimal config that reproduces the issue.
  4. Post a minimal kitty.conf/bashrc that reproduces the issue on your machine

@davegregg
Copy link
Author

  1. With an empty bash config and and an empty kitty.conf, the problem does not occur.
  2. After experimentation, I can reproduce the glitch with only one line enabled in kitty.conf:
background_opacity         0.8
  1. With this minimal config the glitch seems to be rarer. It took me a several seconds of resizing to find a window size where the glitch appears.

@davegregg
Copy link
Author

And why do you think it has anything to do with icat since you said that it happens even with no bash config? If it does not have anything to do with icat, then there can be no involvement of ImageMagick, since icat is the only thing in kitty that uses ImageMagick.

These glitch lines only seem to appear when executing kitty icat <anyimage> (whether manually entered or via bash config). I have tried to reproduce the glitches with other applications and features, but so far I've been unsuccessful, which is why I have been operating on the assumption that it has something to do with icat, even if indirectly.

Before creating my first post, I did try disabling transparency (that was one of the first things I thought to try), but at the time I still got the glitches – which I reported.

But I suspect that during initial testing of transparency, I had left this line enabled:

dynamic_background_opacity yes

Because with...

# background_opacity         0.8
dynamic_background_opacity yes

... I can in fact reproduce the bug, as well, even though the window appears opaque to my eye.

I can re-enabled my entire config and right now it appears that the glitch relates to kitty icat displaying images while either background_opacity is set to a number below 1.0 or dynamic_background_opacity is set to 'yes'.

@davegregg
Copy link
Author

Also with these settings, I can reproduce the bug:

background_opacity         1.0
dynamic_background_opacity yes

@kovidgoyal
Copy link
Owner

OK, I'll try to reproduce the next time I'm on my mac. Just FYI dynamic_background_opacity means you can adjust the opacity using keyboard shortcuts, but the window will still start out opaque. However, if you enable that option the code path used for drawing is the same as when you set an opacity < 1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants