Issue 5 - wmii - Java Swing apps fail to render several pixel rows at the bottoms of windows

Issue 5:	Java Swing apps fail to render several pixel rows at the bottoms of windows	1 of 34 Next ›
	5 people starred this issue and may be notified of changes.	Back to list

Status:	Accepted
Owner:	maglion...@gmail.com
Type-Defect
Priority-Low
Component-WindowManager

Reported by maglion...@gmail.com, Mar 20, 2008

Originally reported by Suraj Kurapa[2]. They appear to fail to render ''n''
pixels on the bottom, where ''n'' is the height of the titlebar, though not
reliably so. Often, there is no issue, often, the gap is significantly
larger, sometimes the entire height of the window.

Original report:

I'm using wmii from hg at changeset:2292.
(Also with deb 3.6+debian-4)

All java programs (which use the Swing GUI toolkit) are not rendering
properly[1]: the bottom 5-10 pixels are missing.

Also, java programs (which use the Swing GUI toolkit) are not receiving the
keyboard focus correctly. When I mouse over a java window, I am forced to
click inside the window and then start typing. The same thing happens if I
use the Mod4-j/k shortcuts to put focus on a java window using my keyboard
-- I still have to click inside the window before I am able to type in it.

Both of these problems did not occur with the previous wmii+ixp-20070516
snapshot.

Thanks for your consideration.

[1] http://snk.tuxfamily.org/tmp/java-render.png
[2] http://www.suckless.org/trac.rc/wmii/ticket/12

Comment 1 by sunaku, May 18, 2008

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!  :-)

Comment 2 by sunaku, May 18, 2008

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

Comment 3 by sunaku, Jun 08, 2008

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.

	Screenshot-OpenOffice.org 2.3.png 28.7 KB View Download

Comment 4 by sunaku, Jun 08, 2008

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.

Comment 5 by anton.maier, Aug 02, 2008

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

Comment 6 by anton.maier, Aug 05, 2008

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

Comment 7 by sunaku, Nov 14, 2008

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

Comment 8 by sunaku, Nov 14, 2008

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

Comment 9 by sunaku, Jan 11, 2009

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

Comment 10 by sunaku, Jan 11, 2009

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.

Status: Fixed

Comment 11 by sunaku, Apr 23, 2009

 Issue 102  has been merged into this issue.

Comment 12 by quesel, May 25, 2009

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

Comment 13 by sunaku, Oct 30, 2009

Resetting issue status since quesel observed problems.

Status: Accepted

Comment 14 by sunaku, Oct 30, 2009

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

Comment 15 by sunaku, Oct 30, 2009

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.

Comment 16 by sunaku, Oct 30, 2009

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.

Comment 17 by mail.ma...@gmail.com, Nov 28, 2009

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.