I submitted the attatched patch for GCJ (with some associated xlib-peer-specific changes), and was asked to get the Classpath changes approved here before checking them in to the GCJ tree. I've also attached a test program which works on GCJ with the patch and not without. GCJ recently merged in the Classpath 0.20 code.
Index: libjava/ChangeLog from Scott Gilbertson <[EMAIL PROTECTED]> * classpath/gnu/java/awt/peer/GLightweightPeer.java (repaint): Pass event to parent. * classpath/java/awt/Graphics.java (hitClip): Handle null clip. Are these changes OK? Justification for the classpath changes, worded relative to GCJ (so "recently merged" means "0.20", for example): GLightweightPeer.repaint contains no code, and the recently-merged Component.repaint no longer passes paint events for lightweight children to their parent Containers. The patch gets GLightweightPeer to send the paint event to the parent like Component used to do. Without the patch, lightweight java.awt.Components don't respond to repaint(). Graphics.hitClip fails if the component's clip is null. Sun's javadoc (1.4.0) says: " This method may use an algorithm that calculates a result quickly but which sometimes might return true even if the specified rectangular area does not intersect the clipping area" and "will never return false unless it can guarantee that the specified rectangular area does not intersect the current clipping area", which to me means "if you're not sure, return true". When the clip is null, we're not sure, so with my patch it returns true. Without the patch, it throws NullPointerException. Sun's javadoc for Graphics.getClip says " If no clip has previously been set, or if the clip has been cleared using setClip(null), this method returns null", so obviously hitClip should be allowing for that. ----- Original Message ----- From: "Bryce McKinlay" Sent: Friday, February 10, 2006 5:27 PM Subject: Re: Patch: Fix painting of lightweight AWT children, not entirely within xlib peers - OK for trunk? > Scott Gilbertson wrote: > > The attached patch gets the following program to work, with both xlib and > > gtk peers, on linux, with week-old code from SVN. The test program doesn't > > work in either case without the patch. > > > > Test program: > > http://gcc.gnu.org/ml/java/2006-02/msg00048/LightweightRepaintTest.java > > > > Most of the changes are in the xlib peers, but some are in classpath code -- > > OK for commit to trunk? > > If so, do I need to make an entry in classpath/ChangeLog? > > > > Hi Scott, > > The changes outside of classpath/ are fine. However, we generally can't > accept changes to the classpath directory that are not already checked > in upstream. So, you'll have to get those changes accepted into > classpath before you can check them in to libgcj. You should post them > on classpath@gnu.org and discuss with the AWT guys there. > > Thanks, > > Bryce > > >
LightweightRepaintTest.java
Description: Binary data
Index: libjava/classpath/gnu/java/awt/peer/GLightweightPeer.java =================================================================== --- libjava/classpath/gnu/java/awt/peer/GLightweightPeer.java (revision 110719) +++ libjava/classpath/gnu/java/awt/peer/GLightweightPeer.java (working copy) @@ -227,7 +227,12 @@ public class GLightweightPeer public void print(Graphics graphics) {} - public void repaint(long tm, int x, int y, int width, int height) {} + public void repaint(long tm, int x, int y, int width, int height) + { + Component p = comp.getParent (); + if(p != null) + p.repaint(0,x+comp.getX(),y+comp.getY(),width,height); + } public void requestFocus() {} Index: libjava/classpath/java/awt/Graphics.java =================================================================== --- libjava/classpath/java/awt/Graphics.java (revision 110719) +++ libjava/classpath/java/awt/Graphics.java (working copy) @@ -617,6 +617,9 @@ public abstract class Graphics */ public boolean hitClip(int x, int y, int width, int height) { + Shape clip = getClip(); + if (clip == null) + return true; return getClip().intersects(x, y, width, height); }