Using i3-gaps with i3blocks causes flickering in i3bar

[nim-]

Hi again

I saw you made an issue on the i3 github repo completely by chance as I was installing i3blocks (and i3-gaps of course) to my laptop, but I don't know whether the issue lies within i3blocks or i3-gaps. I've been an avid user of i3blocks and actually talked to Vivien about using it with your fork a little while abck. I was very kindly given instructions to add a few lines to the i3blocks file block.h and then compile:

http://pastebin.com/wbgZFZar (this is line 39-59 in block.h)

and now i3blocks works with your fork, however, when I use the border options you added, it causes -very- annoying flickering multiple times a second independently of my interval settings it my i3blocks.conf, and the issue didn't seem to be with i3blocks.

Is this something on my end or is it a bug in i3-gaps?

Regardless, I at least hope the block.h file modification is useful to you anyway.

Thanks!

[Airblader]

Hi,

I had figured out the necessary changes already, but thanks anyway. :) Might be a good thing that there's at least two people interested in this already :) I'd just prefer not patching i3blocks as it requires me to maintain that as well, though I guess it wouldn't be so bad. What did Vivien tell you about the patch back then?

About the flickering: I haven't seen this before, ever, nor heard about it (but I honestly doubt many people use the border settings anyway). I will see if I can reproduce it using i3blocks to display my borders.

Just to make sure though:

• Do you only see this on your laptop or on another install, too?
• Do you only see it in combination with i3blocks or without it too (or have you not tried anything else)?
• Can you share your i3blocks config?
• Are you using i3-gaps or i3-gaps-next?
• What distribution are you running?
• Can you describe the flickering more? What exactly flickers and how?

Edit: gave it a quick try and can't reproduce it right away.

[nim-]

We didn't really talk about much else than adding the lines to the file and
the flickering, which Vivien didn't believe to be i3blocks related. Some
googling reveals similar issues from users using conky when the JSON array
isn't on one single line or something like that; that's sadly all I know.
We also briefly discussed if a script could return a background or border
value, e.g. dynamically setting the background color to red if the volume
is muted in a volume script or something similar, which on an unrelated
note might be implemented into i3blocks soon in relation to a part of
another feature request by another user.

I don't know if the above info is useful to you, but there you go; that's
what we discussed.

• I've only tried on my laptop, but I tried on both on clean installs of
  debian Jessie and fedora 21. I wouldn't mind trying other distributions in
  virtual machines if you want me to though.
  *I've not tried anything else.
  *I'll upload it tomorrow
  *i3-gaps
  *Currently fedora 21 on all my pcs

If you need any other information just ask :)
Thanks

Hi,

I had figured out the change necessary already, but thanks anyway. Might be
a good thing that there's at least two people interested in this already :)
I'd just prefer not patching i3blocks as it requires me to maintain that as
well, though I guess it wouldn't be so bad. What did Vivien tell you about
the patch back then?

About the flickering: I haven't seen this before, ever, nor heard about it
(but I honestly doubt many people use the border settings anyway). I will
see if I can reproduce it using i3blocks to display my borders.

Just to make sure though:

• Do you only see this on your laptop or on another install, too?
• Do you only see it in combination with i3blocks or without it too (or
  have you not tried anything else)?
• Can you share your i3blocks config?
• Are you using i3-gaps or i3-gaps-next?
• What distribution are you running?

—
Reply to this email directly or view it on GitHub
#36 (comment).

[Airblader]

Some googling reveals similar issues from users using conky when the JSON array
isn't on one single line or something like that; that's sadly all I know.

Yes, that issue I know (and have ran into myself). But from the looks of it, i3blocks only outputs a single line per update, so I doubt that's the reason (it definitely is a major performance problem not to have it on one line, though – and would cause flickering). There also is another issue, but that's conky-specific, so it really can't play a role here.

I'd like to try your i3blocks config. At the very least I'd like to write a small script that simulates i3blocks to rule out that that's the issue, but also I'd like to see the output. Since there's a certain chance your config might not run for me, it'd be cool if, next to i3blocks.conf, you could do

i3blocks > /tmp/i3blocks.log

and let it run for a few seconds to half a minute, then cancel it and pastebin that log file.

[nim-]

Sure, I'll do that and upload both as the first thing tomorrow morning (GMT
+1).
On 16 Feb 2015 22:13, "Ingo Bürk" notifications@github.com wrote:

Some googling reveals similar issues from users using conky when the JSON
array
isn't on one single line or something like that; that's sadly all I know.

Yes, that issue I know (and have ran into myself). But from the looks of
it, i3blocks only outputs a single line per update, so I doubt that's the
reason (it definitely is a major performance problem not to have it on one
line, though – and would cause flickering). There also is another issue,
but that's conky-specific, so it really can't play a role here.

I'd like to try your i3blocks config. At the very least I'd like to write
a small script that simulates i3blocks to rule out that that's the issue,
but also I'd like to see the output. Since there's a certain chance your
config might not run for me, it'd be cool if, next to i3blocks.conf, you
could do

i3blocks > /tmp/i3blocks.log

and let it run for a few seconds to half a minute, then cancel it and
pastebin that log file.

—
Reply to this email directly or view it on GitHub
#36 (comment).

[Airblader]

No worries, we're in the same timezone. :) I'll be at work first anyway, but I can probably give it a quick try and write that shell script for you to try. Unless something funky is going on, I too doubt that this is i3blocks' doing, but I'd just like to rule it out for sure.

[Airblader]

Oh, one more thing: have you tried not using border options? Does the flickering go away? I'd also love some more detail on how exactly it flickers, i.e., what part and in what way (to the best of your abilities – it's probably not too easy to describe).

That's it for now, though. We'll talk tomorrow!

[nim-]

Hi again

Commenting out the border/bg options completely removes the issue, but that's hardly a solution. The flickering only happens when they're on. It also seems to get worse the more blocks (with the border/bg options enabled) there are in the bar. Also, as you're about to see, I may have... borrowed... some aesthetic features from your setup from a while back... :)

Here's the log file:
http://pastebin.com/jjNwyqgA

I also made a gif of the flickering:
http://imgur.com/mYMY15O - notice how it flickers even more when I click on the bar to update it with the mouse (in the start of the recording).

Here's my i3blocks.conf:
http://pastebin.com/797uiedD

Do you need all the scripts (or anything else) as well?

Thanks!

[Airblader]

Thanks for the files. Could you run the log thing again but give it, say, a minute? I have a better understanding of what you mean by flickering now. It seems as if some blocks just disappear for a short moment, which causes the width to change drastically, visually appearing as a flicker.

Is there any chance you can create images from the *.gif frames so that we can find out which blocks go missing?

Also, can you (temporarily) replace all "command" blocks with something like command=echo "Lorem Ipsum"? This should help finding out whether it's one of the scripts misbehaving or i3 itself.

That's a really nice setup btw!

[nim-]

Thank you!

https://github.com/nim-/dotfiles/blob/master/i3blocks.log I couldn't pastebin the log after a minute, as it was too big, so I uploaded it to my outdated git repo.

Here is frame 4:
http://imgur.com/eIriKBX
The disappearing blocks (and their icon-blocks) are all the ones to the right of my uptime block. That's really strange.

Replacing all scripts with echo "Lorem Ipsum" still gives flicker and looks rather silly:
http://i.imgur.com/hRzB4Ut.png
Frequency of flicker unchanged.

Thanks!

[Airblader]

I can sort of reproduce this, but only with excessive scrolling on the bar (which I know you're not doing). I'm sorry that this is sort of a step-by-step process, but could you try to change

fprintf(stdout, "{\"version\":1,\"click_events\":true}\n[[]\n");

to

fprintf(stdout, "{\"version\":1,\"click_events\":false}\n[[]\n");

in i3blocks.c (line 40), then recompile and install via make clean all && sudo make install and use your (unmodified) config to see if it still occurs?

This is, of course, not a fix. I'm just trying to corner the problem.

[Airblader]

Also, this part of your config confuses me:

[Weather label]
full_text=
command=http://www.dmi.dk

Why does it have both a full_text and a command? Also, what happens when the shell "executes" a website? In my case this causes the label to randomly switch between the icon of the text and the Lorem Ipsum I used as a command.

If it's a mistake, please first try fixing this to see if it changes anything, then my other post.

Edit: Is it supposed to be a link, i.e., clicking on it opens the website?

[Airblader]

Just ignore my last comment, I don't think it has anything to do with it anymore. Just try the things from the comment before that.

[nim-]

I edited and compiled i3blocks as you said, but it made no difference unfortunately.

That part of the config is from here:
https://github.com/vivien/i3blocks/wiki/FAQ#how-can-i-simulate-a-button

I just forgot to add "firefox" in front of it. Doesn't have any effect on the flickering now that it's been corrected in my config either way though.

Thanks a lot for your time, I appreciate it a lot!

[Airblader]

Thanks. It's good to know that the change didn't make it better. I have a theory that I'll have to check up on.

[Airblader]

So my current suspicion is that i3 is "too slow" reading the JSON input, causing it to occasionally rerender the bar while it is in the middle of parsing a new line and doesn't have all blocks parsed yet.

It totally explains what is happening, though it would make it seem odd that it always cuts off after the same block — we don't really know that that's the case, though.

I will try to prepare a crude fix that forces it to wait until it's parsed before rendering, but if it turns out to be the case I'll have to talk to Michael about this as it's an i3 issue and one that affects the design of the code.

[nim-]

If that's the case, I do wonder why this only happens with the new border/bg options. But anyway, thanks for working on it!

[Airblader]

My best guess is that the new properties just slow it down. Maybe having sufficiently many blocks will cause the same effect even on vanilla i3. Even buffering might play a role.

We'll see whether waiting works. I'll try to prepare the fix later today. Thanks for your cooperation on everything, it's very much appreciated that you try all these things out!

[nim-]

I'm definitely the one thanking here. Sounds great.

[Airblader]

I've prepared the little hack. Looks promising; to the small extent that I can reproduce this, it seems to work for as much as I can tell. Since you're using gaps, not gaps-next, I've based it off of gaps. Please try

cd <your checkout>
git checkout issue-36-hack && git pull --rebase
make && sudo make install

and then restart i3 to see if it fixes the issue. Crossing my fingers!

Edit: also, please verify that the bar still updates and clicks work etc. Instead of waiting, I simply don't do anything if it's currently parsing a line. Waiting caused a complete hang. But just aborting in that case seemed to work for my little test.

[nim-]

It works!!!

[Airblader]

Okay. I will address this as an issue to i3/i3 to see what we can come up with. Even if no i3 user reported this yet, it does in theory affect them as well.

Meanwhile, you can stay on this branch and use it to have a usable i3bar (and to see if this fix doesn't come with any ramifications we didn't see right now) – if you want, of course.

I'll keep this issue open as long as the i3 issue is open, too.

[nim-]

Yeah, sounds great. I'll stay on this branch.

Thanks so much for your time! I was turning insane because of that bar. Great work man!

[Airblader]

Thanks, no worries. I'll always help as much as I can. Let's hope we can work this out correctly :)

[Airblader]

@nim- I have prepared a more elaborate fix for this (see i3/i3#1481). I'll wait for Michael's comments first since I got a strong feeling that he's gonna have problems with the fix (my C is actually fairly bad).

But once (and if) we agreed on the fix, it'd be great if you could verify the new fix before it's merged.

[nim-]

Yeah sure, just tell me and I'll do what I can to help out.

[Airblader]

@nim- Since it seems to be taking a bit, would you mind trying the fix out in the meantime? See if it works, if anything else breaks or whatever. I've been using it since I fixed it and haven't had problems.

git checkout feature-statusline-buffer && git pull && make && sudo make install

I'll let you know, of course, once the fix is merged.

[nim-]

Of course, I'm using it now. Will report back if any bugs occur but it works very well right now :)

[Airblader]

@nim- The patch has been merged now :) i3-gaps has been updated, though the fix is only on gaps-next (but gaps is almost identical due to the 4.9 release yesterday anyway). You can switch back now. Thanks for all your help!

git checkout gaps-next && git pull
make && sudo make install

[nim-]

Thank you for your hard work. It is still working well :)