[Original comment by lemaire.adrien@…]

log file is 6.8M . Will start another session while running immediately urxvt, I suspect it to help the bug coming sooner. Will upload the log file afterwards

[Original comment by lemaire.adrien@…]

Bug always occur after some time with default conf, but log file is too big at this time.
Bug occurs much more faster with my custom conf (or is this pure coincidence ?)

I attach my custom conf as well in case

[Original comment by quark@…]

I also encounter this bug sometimes (randomly) in TopCoder Arena Java swing applet.

If the window is enlarged, partial content is shown as attchments i3-swing-* shown.

[Original comment by dakra-i3wm@…]

I have the same problem (i3 version: 4.2 (2012-04-25, branch "release-4.2") and (oracle) java version "1.6.0_32").
Most disturbing when working with popups (like settings/vcs) in the pycharm/intellij editor.

[Original comment by Klaas Boesche <klaas-dev@…>]

I have this bug too. Happens in floating as well as tiled windows. Seems to be random and reopening the window sometimes/rarely leads to it being shown correctly.
Happening here with current git version: i3 version 4.3-153-g305b6dd (2012-11-13, branch "next") and OpenJDK 1.7.0_09 on ArchLinux 64bit and in particular with Netbeans, but other Java programs as well.
Will have a look at my log as well...

[Original comment by Klaas Boesche <klaas-dev@…>]

The right search terms help a lot when googling: http://bababadalgharaghtakamminarronnkonnbro.blogspot.de/2012/07/topcoder-arena-resizing-bug-in.html
It seems to be a deficiency of the JVMs which has to do with non-reparenting window managers. See the blog post or this: http://tools.suckless.org/wmname for workarounds.
So, not an i3 bug, can be closed?

Replying to comment 6 by Klaas Boesche <klaas-dev@…>:

The right search terms help a lot when googling: http://bababadalgharaghtakamminarronnkonnbro.blogspot.de/2012/07/topcoder-arena-resizing-bug-in.html
This post talks about non-reparenting window managers, but i3 is a reparenting window manager. That is, the post does not apply.

[Original comment by Anders Aagaard <aagaande@…>]

I run into this issue with intellij quite often.

[Original comment by xeen]

workaround: restarting i3 in place (usually $mod+shift+r) renders the windows correctly for me. Most of the time this is easier than having to deal with the unreadable windows.

[Original comment by matt.garriott@…]

I'm experiencing the same issue with a swing app called tinyuml https://aur.archlinux.org/packages/tinyuml/
I've attached a stack trace I received when the program started failing to render in the hopes that it will be helpful.

My System:
3.8.6-1-ARCH x64
i3 version 4.5.1-21-g0a3d42c (2013-03-27, branch "next")

Please let me know if I can provide any additional information.

[Original comment by matt.garriott@…]

Looks like I may have jumped the gun a bit. I am able to cause the same rendering error while running openbox, so unless i3 and openbox share a common problem it is probably safe to disregard my previous comment.

Sorry about the false alarm.

[Original comment by daniel@…]

After some debugging and experimenting i think i found out whats causing the problem.

When you look closely at a window (like attachment:cgoban_window_not_drawn.png) that's not painted you can notice a 10x10 pixel square (top left in the window) that actually shows the content that should be there.

In x.c, method

void x_con_init(Con *con, uint16_t depth) {
    /* TODO: maybe create the window when rendering first? we could then even
     * get the initial geometry right */

you find the following lines of code

    Rect dims = { -15, -15, 10, 10 };
    con->frame = create_window(conn, dims, depth, visual, XCB_WINDOW_CLASS_INPUT_OUTPUT, XCURSOR_CURSOR_POINTER, false, mask, values);

Pay attention to the TODO in the method header and the initial size windows are created (10x10 pixel) initially. It seems like there is some race condition in the JVM that sometimes fail to handle windows that get created with a geometry that doesn't match the requested size.

Changing the code to

    Rect dims = { -15, -15, 2000, 2000 };
    con->frame = create_window(conn, dims, depth, visual, XCB_WINDOW_CLASS_INPUT_OUTPUT, XCURSOR_CURSOR_POINTER, false, mask, values);

solves the problem. At least for all windows that are smaller than 2000x2000 pixel.

After making that change, the code posted in #934 (comment:3:#934) always renders the popup. No random grey windows anymore.

[Original comment by xeen]

I’ve been using the proposed workaround for about a month now and can’t remember seeing any blank windows.

[Original comment by robert]

I still get the issue with the proposed workaround. For me, changing need_reparent = true in x_con_init seems to fix the issue. At least in intellij and the dialog popup test from #934.

[Original comment by daniel@…]

Replying to comment 14 by robert:

I still get the issue with the proposed workaround. For me, changing need_reparent = true in x_con_init seems to fix the issue. At least in intellij and the dialog popup test from #934.

can you post some snippet of code to clarify what you have changed in your code, i'm not quite sure what you changed and would like to experiment a bit.

[Original comment by robert]

Replying to comment 15 by daniel@…:

Replying to comment 14 by robert:

I still get the issue with the proposed workaround. For me, changing need_reparent = true in x_con_init seems to fix the issue. At least in intellij and the dialog popup test from #934.

can you post some snippet of code to clarify what you have changed in your code, i'm not quite sure what you changed and would like to experiment a bit.

Yes, it differs a bit from 4.5.1 tag to master branch.

My change in 4.5.1 tag, you can compare this to master branch where the diff would be different.

diff --git a/src/x.c b/src/x.c
index fcb63c3..70148d4 100644
--- a/src/x.c
+++ b/src/x.c
@…) {
     state->id = con->frame;
     state->mapped = false;
     state->initial = true;
+    state->need_reparent = true;
     CIRCLEQ_INSERT_HEAD(&state_head, state, state);
     CIRCLEQ_INSERT_HEAD(&old_state_head, state, old_state);
     DLOG("adding new state for window id 0x%08x\n", state->id);

This ticket was fixed in commit http://c.i3wm.org/0c7a76c2:

Handle the _NET_REQUEST_FRAME_EXTENTS ClientMessage (java compat)

This ClientMessage can be used to estimate how big the window will be
before opening it. Java always sends the ClientMessage and checks the
atom that should be set by the window manager, but it seems that the
fallback code path has a race condition.

Let’s see if the situation gets better with this change. I have been
running this patch for about two weeks and have not seen any issues with
it.

fixes #934
fixes #709