search

guodong / wmii

Automatically exported from code.google.com/p/wmii
MIT License
0 stars 0 forks source link

Java Swing apps fail to render several pixel rows at the bottoms of windows #5

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
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

Original issue reported on code.google.com by maglion...@gmail.com on 20 Mar 2008 at 7:45

GoogleCodeExporter commented 8 years ago 
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!  :-)

Original comment by sunaku on 18 May 2008 at 9:54

GoogleCodeExporter commented 8 years ago 
I should clarify that the 5--10 missing pixels problem still exists in wmii.

Original comment by sunaku on 18 May 2008 at 9:55

GoogleCodeExporter commented 8 years ago 
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.

Original comment by sunaku on 8 Jun 2008 at 2:26

Attachments:

GoogleCodeExporter commented 8 years ago 
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.

Original comment by sunaku on 8 Jun 2008 at 2:28

GoogleCodeExporter commented 8 years ago 
ive got a solution, after removing wallpaper it works the right way...

Original comment by anton.ma...@gmail.com on 2 Aug 2008 at 5:53

GoogleCodeExporter commented 8 years ago 
http://codesnippets.joyent.com/posts/show/1499

Original comment by anton.ma...@gmail.com on 5 Aug 2008 at 1:29

GoogleCodeExporter commented 8 years ago 
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

Original comment by sunaku on 15 Nov 2008 at 12:24

GoogleCodeExporter commented 8 years ago 
Never mind, the problem is back again, even with the XToolkit flag.  *sigh*

Original comment by sunaku on 15 Nov 2008 at 12:44

GoogleCodeExporter commented 8 years ago 
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".

Original comment by sunaku on 11 Jan 2009 at 7:18

GoogleCodeExporter commented 8 years ago 
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.

Original comment by sunaku on 12 Jan 2009 at 5:14

GoogleCodeExporter commented 8 years ago 
Issue 102 has been merged into this issue.

Original comment by sunaku on 23 Apr 2009 at 5:53

GoogleCodeExporter commented 8 years ago 
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...

Original comment by que...@gmail.com on 25 May 2009 at 2:32

GoogleCodeExporter commented 8 years ago 
Resetting issue status since quesel observed problems.

Original comment by sunaku on 30 Oct 2009 at 3:40

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

Original comment by sunaku on 30 Oct 2009 at 3:41

GoogleCodeExporter commented 8 years ago 
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.

Original comment by sunaku on 30 Oct 2009 at 3:48

GoogleCodeExporter commented 8 years ago 
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.

Original comment by sunaku on 30 Oct 2009 at 3:53

GoogleCodeExporter commented 8 years ago 
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.

Original comment by mail.ma...@gmail.com on 28 Nov 2009 at 6:48

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

Original comment by sunaku on 2 Mar 2010 at 11:51

GoogleCodeExporter commented 8 years ago 
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. ;-)

Original comment by mail.ma...@gmail.com on 3 Mar 2010 at 2:33

GoogleCodeExporter commented 8 years ago 
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.

Original comment by benizi on 7 Jul 2010 at 7:19

GoogleCodeExporter commented 8 years ago 
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.

Original comment by maglion...@gmail.com on 7 Jul 2010 at 7:46

GoogleCodeExporter commented 8 years ago 
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. ;))

Original comment by mail.ma...@gmail.com on 7 Jul 2010 at 7:56

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

Original comment by maglion...@gmail.com on 7 Jul 2010 at 8:08

GoogleCodeExporter commented 8 years ago 
Ups - my mistake! I confused wmii with dwm, which is non-reparenting.

Original comment by mail.ma...@gmail.com on 7 Jul 2010 at 8:13

GoogleCodeExporter commented 8 years ago 
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.

Original comment by maglion...@gmail.com on 7 Jul 2010 at 9:32

GoogleCodeExporter commented 8 years ago 
This issue was closed by revision 1f68667775.

Original comment by maglion...@gmail.com on 8 Jul 2010 at 7:07