I just built classpath 2006.05.31 cvs on Linux SuSE 8.2 (upgraded to GTK 2.8), and I experience some strange repaint issues. Some regions of the app windows seem to be never repainted, while others (anely topleft) are sometimes (partially) repainted when the window becomes visible after window manager operations. See the attached screenshot for an example; I also attach the (unfinished) sourcecode of the test app in question. Just compile, then run jamvm xxx.SudokuGUI press "Random Game" button (if you can see it), and then "Solve" (or use mouseclicks to do it yourself). I also get massive repaint problems when scrolling components inside JSplitPanes. Best, Norman
Created attachment 11544 [details] screenshot showing the repaint issue
Created attachment 11545 [details] source code for testcase
Created attachment 11546 [details] source code for testcase (main app)
Created attachment 11547 [details] source code for testcase (recursive brute-force solver)
Basically, parts of the application view are not painted. The bug appeared after the big rearrangements, making Graphics2D default. There is no need to use any test case, the Swing demo is currently not working as expected. I set a high priority because I am not even sure if we can make an ordinary release before this is fixed.
I am also seeing a similar thing with our free swing demo example. But Sven isn't seeing the same thing (we compared screenshots and his looks fine, while mine look like attachement #1). So another example might be nice to see if we can figure out when/how this is happening. It looks like this example is missing the SudokuRepaintable class: package xxx; public interface SudokuRepaintable { public void repaintRequested(Object o); } With that it compiles and I do see similar repaint issues as in the original bug report when hiding and exposing the window again after Random Game and Solve Animated. Also when I start up xxx.SudokuGUI the menubar is missing. Might this be related somehow to the window manager used? I am using metacity 2.14.5 BTW. The scrolling components inside JSplitPanes was bug #27879 which is now solved.
Mine metacity is: # metacity --version metacity 2.14.3 Copyright (C) 2001-2002 Havoc Pennington, Red Hat, Inc., and others I am currently using Fedora 5 with all recent updates installed. I also tried to check maybe this is some clipping problem. But the broken initial view does not change if I replace cairoClip by empty method.
Created attachment 11586 [details] Screen shoot, showing what is repainted wrongly This image may indicate that is going wrong. When scrolling up and down with JList demo, the JList itself is not repainted, but the regions, needing repainting, are painted above the list frame, creating the damaged rectangle. The X co-ordinates of the area being repainted are correct, but the Y coordinates are translated upward for some strange reason.
Nope, the scrolling issue is a seperate one, related to copyArea, which I think is now fixed. This repaint bug shows up on hiding and re-exposing the window and on resizing and similar. It doesn't seem to be a clipping bug though, because disabling clipping doesn't help. (Although I did discover that swing seems to send some strange clip values sometimes) So at the moment I don't have many ideas on what the problem is.
I see this with openjump too. the intro image is only partly drawn.
Created attachment 11590 [details] The whole computer monitor screen shoot after forcing to repaint the swing demo totally I have removed the Fedora shortcut panel on the top of the window and discovered that the bug is NOT observed if the Swing Demo appears in the absolute screen position 0,0 - the real top left corner. The problems appear after I move the Demo application window into another location. Even more, if I move the Demo window with broken internal frames back to the 0,0 location, they are repainted correctly again. When I force to repaint the all window (by temporary covering it with another, larger application window), it seems that the width (height) of the non-repainted areas is equal to the left (top) distance of the window from the screen edge. As if something is updated with the incorrect sign or incorrect direction. This is interestingly regular, so I decided to upload one more screen shoot. My previous picture was influenced by the fact that natives were not compiled, but this should be OK now, as I have just done fresh check in and did the build from console. As long as I keep the window at 0,0, there are no any noticeable problems, related to resizing.
Actually, it appears to be a clipping bug indeed. The clipping impl is all bad. I'll fix it.
I just tested openjump with the latest CVS version of classpath, and the problem was fixed.
Created attachment 11595 [details] Seems fixed, just several remaining nonsenses Great! The basic functionality has returned! In the Swing demo, the bottom border of the windows seems incompletely painted, and I can drag internal frames into the unused tool bar area where they leave unrepainted traces. This is, however, nothing in comparison from what it was! Congratulations! I upload the desktop view, demonstrating the several remaining problems.
Seems improved a lot by the following 2 patches: 2006-06-02 Sven de Marothy <sven@physto.se> * gnu/java/awt/peer/gtk/CairoGraphics2D.java (cairoPreserveClip, cairoResetClip): New methods. (setClip, clip): Reimplement. * native/jni/gtk-peer/gnu_java_awt_peer_gtk_CairoGraphics2D.c * include/gnu_java_awt_peer_gtk_CairoGraphics2D.h (cairoPreserveClip, cairoResetClip): New methods. 2006-06-05 Sven de Marothy <sven@physto.se> * gnu/java/awt/peer/gtk/ComponentGraphics.java (ComponentGraphics): Use 0,0 as clip origin. Things are mostly usable again now. Only some small artifacts as described by Audrius in comment #14 remain.
Created attachment 11600 [details] source code for testcase Uploaded the missing file for the testcase...
Created attachment 11601 [details] screenshot (first time Hades starts up with Java2D on free VM)
Created attachment 11602 [details] screenshot (showing menu repaint issue)
I just re-tested with current CVS, and I confirm that most repaint issues are fixed now. This is the first time I can start my (so far, non-free) circuit simulator on a free VM with Java2D enabled; see attached screenshot. The second new screenshot shows a problem with JMenus, which are totally or partially overwritten in my app (which periodically triggers repaints on the main canvas from a timer thread). I have no simple testcase for this yet, and menus in the Swing demo seem to behave normally. However, running the 'FillRect' test in the Swing demo and then activating a menu shows a massive slowdown on my system. FillRect still reports a repaint time of 60ms, but actual repaints only occur once every few seconds.
Subject: Bug 27833 CVSROOT: /cvsroot/classpath Module name: classpath Changes by: Roman Kennke <rabbit78> 06/06/07 19:12:04 Modified files: gnu/java/awt/peer/gtk: CairoGraphics2D.java . : ChangeLog Log message: 2006-06-07 Roman Kennke <kennke@aicas.com> PR 27833 * gnu/java/awt/peer/gtk/CairoGraphics2D.java (clip(Shape)): Implemented correctly, so that the current shape gets intersected by the parameter shape. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/awt/peer/gtk/CairoGraphics2D.java?cvsroot=classpath&r1=1.14&r2=1.15 http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpath&r1=1.7701&r2=1.7702 Patches: Index: ChangeLog =================================================================== RCS file: /cvsroot/classpath/classpath/ChangeLog,v retrieving revision 1.7701 retrieving revision 1.7702 diff -u -b -r1.7701 -r1.7702 --- ChangeLog 7 Jun 2006 19:01:07 -0000 1.7701 +++ ChangeLog 7 Jun 2006 19:12:03 -0000 1.7702 @@ -1,3 +1,10 @@ +2006-06-07 Roman Kennke <kennke@aicas.com> + + PR 27833 + * gnu/java/awt/peer/gtk/CairoGraphics2D.java + (clip(Shape)): Implemented correctly, so that the current shape + gets intersected by the parameter shape. + 2006-06-07 Andrew John Hughes <gnu_andrew@member.fsf.org> * java/math/BigDecimal.java: @@ -33,7 +40,7 @@ * NEWS: Documented the above. * java/io/File.java: Javadoc fix. -2006-06-06 Roman Kennke <kennke@aicas.com> +2006-06-07 Roman Kennke <kennke@aicas.com> PR 27920 * javax/swing/JTree.java @@ -84,11 +91,11 @@ (setModel): Clear the tables and update the layout. Added null check to prevent NPE. -2006-06-05 Sven de Marothy <sven@physto.se> +2006-06-07 Sven de Marothy <sven@physto.se> * gnu/java/awt/peer/gtk/GdkGlyphVector: Removed file. -2006-06-05 Sven de Marothy <sven@physto.se> +2006-06-07 Sven de Marothy <sven@physto.se> * gnu/java/awt/peer/gtk/FreetypeGlyphVector.java * include/gnu_java_awt_peer_gtk_FreetypeGlyphVector.h
Could everybody run his test programs again and report if there are still problems? I don't have any problems left.
> Could everybody run his test programs again and report if there are still > problems? I don't have any problems left. "Simple" things seem to work well again. I still see all sorts of problems with JSplitPane. (In my image viewer, both the JTree with the filenames and the main image canvas seem to randomly overwrite parts of the split pane dividers, and sometimes things are blit into wrong regions of the viewports. Probably some wrong clip remaining somewhere in JViewPort.) The menu-overwritten-issue is still there. I have no simple testcase, but here are the steps to reproduce it: 1. Download http://tams-www.informatik.uni-hamburg.de/applets/hades/archive/hades.jar 2. Run jamvm -jar hades.jar 3. Select menu > help > demos > clockgen 4. Wait two seconds until the demo begins 5. Try to open a menu 6. I personally like menu > layers the best: somehow two different parts of the menu are redrawn when the LED connected to the upper clock generator is updated :-) 7. The component uses its own backbuffer, and calls repaint(x,y,w,h) with handcalculated screen coordinates during the animation repaints. 8. Any ideas on how to debug this?
(In reply to comment #21) > Could everybody run his test programs again and report if there are still > problems? I don't have any problems left. Yep, good stuff. It seems all clipping regressions I was seeing are fixed now. I don't know whether the issue reported in comment #22 is a regression or a new bug.
The problems I previously reported are no longer observed.
OK, let's close this bug unless somebody else protests. The JSplitPane/JViewport issue is not a regression; those clipping bugs are much older than the Graphics2D rework. Menus in the swing demo work fine for me, even when running the paint performance animation. Therefore, the menus-overpainted bug in my test app is not due to the menus or the animation repaints. I suspect some unlucky interaction of the various set/get clip calls. Do we have another test application which calls and tests repaint(x,y,w,h), that I might test on my system?
Component painting seems good on my installation, but I now see a regression in the chart drawing for the JFreeChart demos. I'll investigate to see when this regression occurred exactly (it was working nicely on Monday).
(In reply to comment #26) > Component painting seems good on my installation, but I now see a regression in > the chart drawing for the JFreeChart demos. I'll investigate to see when this > regression occurred exactly (it was working nicely on Monday). > I tested a JFreeChart demo with Classpath from CVS immediately before and immediately after Roman's patch, and it is this patch that introduces the regression in the JFreeChart drawing. However, I think the patch is correct and most likely it is just revealing another bug elsewhere. I'll file a separate bug once I've looked at it some more...
This might or might not be related to my menu problem, but I just got a nice screenshot of another clipping issue while playing with a testcase for JToolTip (now bug #27957). See http://gcc.gnu.org/bugzilla/attachment.cgi?id=11636&action=view I got the same tooltip to be drawn at three different places (and I fear I am going mad, but I swear that the newest tooltip in the screenshot is the bottommost one. So the active tooltip somehow ended up clipped by the remains of the previous ones...)
(In reply to comment #27) > However, I think the patch is correct > and most likely it is just revealing another bug elsewhere. I'll file a > separate bug once I've looked at it some more... I think the JFreeChart problem is in the setTransform() method, I filed a separate bug report (and Mauve tests) for this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27960
Can this be closed now? I fixed the clipping/translation related bugs, the new mauve tests all pass now (except for one, which is actually testing a bug in Sun's impl and where we behave according to the spec). Most Swing apps seem to be ok now too.
All my test apps and this sudoku example look fine again.
(In reply to comment #22) > > Could everybody run his test programs again and report if there are still > > problems? I don't have any problems left. > > "Simple" things seem to work well again. Lets close this bug. And lets open 2 new bug reports for... > I still see all sorts of problems with JSplitPane. (In my image viewer, both > the JTree with the filenames and the main image canvas seem to randomly > overwrite parts of the split pane dividers, and sometimes things are blit into > wrong regions of the viewports. Probably some wrong clip remaining somewhere in > JViewPort.) And... > The menu-overwritten-issue is still there. I have no simple testcase, but here > are the steps to reproduce it: > > 1. Download > http://tams-www.informatik.uni-hamburg.de/applets/hades/archive/hades.jar > 2. Run jamvm -jar hades.jar > 3. Select menu > help > demos > clockgen > 4. Wait two seconds until the demo begins > 5. Try to open a menu > 6. I personally like menu > layers the best: somehow two different parts of the > menu are redrawn when the LED connected to the upper clock generator is > updated :-) > 7. The component uses its own backbuffer, and calls repaint(x,y,w,h) with > handcalculated screen coordinates during the animation repaints. > 8. Any ideas on how to debug this? I am also seeing both issues, but it seems better to separate these into their own bug reports since they seem unrelated to the original issue reported here.
(In reply to comment #30) > Can this be closed now? I fixed the clipping/translation related bugs, the new > mauve tests all pass now (except for one, which is actually testing a bug in > Sun's impl and where we behave according to the spec). Most Swing apps seem to > be ok now too. Well, I was just writing about the same as Mark, but he was faster :-) I'll try to isolate the repaint/clipping bugs I see with my tests and submit more detailed bugreports asap.
Closed. BTW. Hades looks very nice. Looking forward to the bug report and trying it out again :)