Using i3-gaps with i3blocks causes flickering in i3bar about i3 HOT 29 CLOSED

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.

from i3.

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).

from i3.

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.

from i3.

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" [email protected] 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).

from i3.

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.

from i3.

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!

from i3.

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!

from i3.

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!

from i3.

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!

from i3.

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.

from i3.

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?

from i3.

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.

from i3.

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!

from i3.

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.

from i3.

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.

from i3.

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!

from i3.

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!

from i3.

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

from i3.

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.

from i3.

It works!!!

from i3.

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.

from i3.

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!

from i3.

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

from i3.

@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.

from i3.

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

from i3.

@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.

from i3.

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

from i3.

@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

from i3.

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

from i3.