Java Swing apps fail to render several pixel rows at the bottoms of windows about wmii HOT 26 CLOSED

I am happy to report that the keyboard focus problems with Java Swing programs 
have
been solved about a month ago (sorry for the late report).  There have been
simultaneous changes in both wmii and jedit codebase, so I'm not exactly which
project fixed the problem.  Anyway, many thanks and kudos to both projects!  :-)

I should clarify that the 5--10 missing pixels problem still exists in wmii.

The missing pixels problem also occurs with OpenOffice 2.3  (I did not test 
previous
versions because I rarely use OpenOffice).  See attached screen-shot.

Aha!  Upon closer inspection of the previous screenshot, it seems that this bug 
is
due to the logic that puts padding around XTerms to hide the X root background!

I am using wmii-hg2338 by the way.

ive got a solution, after removing wallpaper it works the right way...

http://codesnippets.joyent.com/posts/show/1499

The MToolkit did not solve the problem for me.  Instead, the X11.XToolKit did.
(hurray!! finally! :-)

Now I run jEdit like this (passing the XToolkit flag):

  java -Dawt.toolkit=sun.awt.X11.XToolkit jedit.jar

For more information about these toolkit flags, see:

  http://java.sun.com/j2se/1.5.0/docs/guide/awt/1.5/xawt.html

Never mind, the problem is back again, even with the XToolkit flag.  *sigh*

Solution:  Use OpenJDK 6 (IcedTea) instead of Sun Java 6 and set your java
application (jEdit in my case) to draw window & dialog borders using "Swing 
look & feel".

Setting bug status to fixed.  Use the solution I posted in the previous 
comment, or
re-open this bug if my solution does not work.

Issue 102 has been merged into this issue.

I now tried to use OpenJDK 6 and at least with version
java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.4.1) (6b14-1.4.1-0ubuntu7)
OpenJDK 64-Bit Server VM (build 14.0-b08, mixed mode)

the problem still remains... so sometimes half of my application is not drawn...

additionally the whole application looks wierd as open jdk seams to have font 
issues...

Resetting issue status since quesel observed problems.

Kris, I think changeset 2580 "Fix unnecessary SIGWINCHes when unmapping 
clients." has
helped reduce the occurrence of this problem in my environment.

I think this issue is caused by Java querying the window size at an unstable 
time ---
when wmii is still mapping/resizing/whatever it.  If Java gets into this state 
when a
window is first opened, it consistently does this for the life of that window 
---
even after window resizing.

One thing that has helped immensely for me is to open Java GUI apps in the 
floating
layer and then move them to the managed layer.  This way, I avoid this gray-bar 
issue
98% of the time.   Perhaps this behavior hints at the root cause of this issue?

Thanks for your consideration.

I tried one experiment:

1. I opened & closed the file-open dialog in jEdit until the gray-bar issue 
occurred.
2. I killed and reran wmii (without killing the X server).
3. The gray-bar was gone!  :-)

When the new wmii started, it somehow reprocessed all existing clients, and this
fixed the gray-bar issue.  Does this explain anything about the root cause of 
this issue?

Thanks.

Same problem here:
Gentoo Sun JDK 1.6.0.17 & NetBeans
Chances that a Java window is rendered correctly is about 40%. Very annoying :(
Doesn't matter whether it is floating or not.

OpenOffice used to have a similar problem (extra space between menu bar and 
window
title bar), but with the update to 3.1.1 this problem is gone.

Anyway - resizng ooffice always fixed the render problem, while resizing Java 
windows
does not help.

I finally switched from jEdit to Vim, so I don't care about this issue anymore. 
 Yay 
:)

I still use NetBeans+jVi (http://jvi.sourceforge.net) so I still care - anyway 
the
problem not only exists for NetBeans itself, but also for the software I 
develop. ;-)

I just ran into this problem when taking NetBeans for a test drive.  I noticed 
via xwininfo that enlightenment (some old E17 prerelease?) reports typical 
windows' upper-left as:

absolute:(x+borderwidth,y+titleheight), relative:(0,0)

whereas wmii reports a similar-looking window's upper-left position as:

absolute:(x+borderwidth,y+titleheight), relative:(borderwidth,titleheight).

So, guessing that Java AWT wasn't handling the relative positioning, I 
decreased the titlebar height to virtually nothing:

wmiir xwrite /ctl 'xft:Nonexistent-0'

Disregarding the side effect of losing all wmii text, this fixed the button 
positioning in NetBeans.

Unfortunately, that doesn't mean anything other than that E17 reparents windows 
twice and places them at the upperleft of the last parent. Most window managers 
don't do that, so it's not a likely culpret. At any rate, there's nothing for 
the apps to handle. They do all of their drawing relative to their own windows. 
I expect that the problem is that AWT does some unnecessary compensations that 
require unwarrented assumptions.

Because of that bug I'm currently using Xmonad (http://xmonad.org) which also 
is a non-reparenting window manager with title bars and everything, but all 
Java programs render correctly there. So I'd guess it's unlikely a bug in AWT. 
(But that, of course, is just a wild guess. ;))

Hm? wmii and E17 are both reparenting window managers. At any rate, it is, 
without question, a but in AWT.

Ups - my mistake! I confused wmii with dwm, which is non-reparenting.

Ugh. I'm sorry to say that I've looked into the AWT source, and the problem is 
a worse kind of depraved inanity than I could have expected. From what I can 
tell, AWT creates a content window inside of its client window. It makes (or 
tries to make) that window the size of the window manager frame window, then 
gives it negative offsets to align with the origin of the frame, and then draws 
its content at a positive offset from its own origin. It seems that if, for 
some reason, it grabs its window size at the precise wrong moment, it sets the 
location of its content window based on those assumed offsets, but draws its 
content based on updated assumptions of its offsets. My head hurts.

This issue was closed by revision 1f68667775.