Bug 27833 - Strange repaint bugs after Graphics2D update
Summary: Strange repaint bugs after Graphics2D update
Status: RESOLVED FIXED
Alias: None
Product: classpath
Classification: Unclassified
Component: swing (show other bugs)
Version: 0.92
: P2 critical
Target Milestone: 0.92
Assignee: Roman Kennke
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-05-31 09:51 UTC by Norman Hendrich
Modified: 2006-06-13 13:34 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-06-02 21:15:56


Attachments
screenshot showing the repaint issue (32.24 KB, image/gif)
2006-05-31 09:52 UTC, Norman Hendrich
Details
source code for testcase (1.79 KB, text/plain)
2006-05-31 09:53 UTC, Norman Hendrich
Details
source code for testcase (main app) (3.34 KB, text/plain)
2006-05-31 09:53 UTC, Norman Hendrich
Details
source code for testcase (recursive brute-force solver) (2.74 KB, text/plain)
2006-05-31 09:53 UTC, Norman Hendrich
Details
Screen shoot, showing what is repainted wrongly (60.11 KB, image/png)
2006-06-03 08:26 UTC, Audrius Meškauskas
Details
The whole computer monitor screen shoot after forcing to repaint the swing demo totally (92.27 KB, image/png)
2006-06-03 18:46 UTC, Audrius Meškauskas
Details
Seems fixed, just several remaining nonsenses (86.46 KB, image/png)
2006-06-05 08:08 UTC, Audrius Meškauskas
Details
source code for testcase (126 bytes, text/plain)
2006-06-06 07:53 UTC, Norman Hendrich
Details
screenshot (first time Hades starts up with Java2D on free VM) (40.02 KB, image/jpeg)
2006-06-06 08:17 UTC, Norman Hendrich
Details
screenshot (showing menu repaint issue) (44.77 KB, image/gif)
2006-06-06 08:18 UTC, Norman Hendrich
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Norman Hendrich 2006-05-31 09:51:43 UTC
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
Comment 1 Norman Hendrich 2006-05-31 09:52:21 UTC
Created attachment 11544 [details]
screenshot showing the repaint issue
Comment 2 Norman Hendrich 2006-05-31 09:53:03 UTC
Created attachment 11545 [details]
source code for testcase
Comment 3 Norman Hendrich 2006-05-31 09:53:23 UTC
Created attachment 11546 [details]
source code for testcase (main app)
Comment 4 Norman Hendrich 2006-05-31 09:53:53 UTC
Created attachment 11547 [details]
source code for testcase (recursive brute-force solver)
Comment 5 Audrius Meškauskas 2006-06-02 21:15:56 UTC
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. 
Comment 6 Mark Wielaard 2006-06-03 05:38:23 UTC
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.
Comment 7 Audrius Meškauskas 2006-06-03 08:18:34 UTC
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.

Comment 8 Audrius Meškauskas 2006-06-03 08:26:11 UTC
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.
Comment 9 Sven de Marothy 2006-06-03 18:08:25 UTC
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.
Comment 10 pere 2006-06-03 18:23:29 UTC
I see this with openjump too.  the intro image is only partly drawn.
Comment 11 Audrius Meškauskas 2006-06-03 18:46:47 UTC
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.
Comment 12 Sven de Marothy 2006-06-03 19:34:16 UTC
Actually, it appears to be a clipping bug indeed. The clipping impl is all bad. I'll fix it.
Comment 13 pere 2006-06-05 07:53:45 UTC
I just tested openjump with the latest CVS version of classpath, and the
problem was fixed.
Comment 14 Audrius Meškauskas 2006-06-05 08:08:06 UTC
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.
Comment 15 Mark Wielaard 2006-06-05 08:20:08 UTC
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.
Comment 16 Norman Hendrich 2006-06-06 07:53:29 UTC
Created attachment 11600 [details]
source code for testcase

Uploaded the missing file for the testcase...
Comment 17 Norman Hendrich 2006-06-06 08:17:26 UTC
Created attachment 11601 [details]
screenshot (first time Hades starts up with Java2D on free VM)
Comment 18 Norman Hendrich 2006-06-06 08:18:15 UTC
Created attachment 11602 [details]
screenshot (showing menu repaint issue)
Comment 19 Norman Hendrich 2006-06-06 08:39:54 UTC
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.




Comment 20 cvs-commit@developer.classpath.org 2006-06-07 19:14:03 UTC
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



Comment 21 Roman Kennke 2006-06-07 19:38:52 UTC
Could everybody run his test programs again and report if there are still problems? I don't have any problems left.
Comment 22 Norman Hendrich 2006-06-08 06:29:03 UTC
> 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?



Comment 23 Mark Wielaard 2006-06-08 11:21:23 UTC
(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.
Comment 24 Audrius Meškauskas 2006-06-08 11:50:38 UTC
The problems I previously reported are no longer observed.
Comment 25 Norman Hendrich 2006-06-08 11:54:32 UTC
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?
Comment 26 david.gilbert 2006-06-08 12:50:52 UTC
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).
Comment 27 david.gilbert 2006-06-08 13:32:51 UTC
(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...
Comment 28 Norman Hendrich 2006-06-08 13:41:47 UTC
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...)
Comment 29 david.gilbert 2006-06-08 15:10:19 UTC
(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
 

Comment 30 Roman Kennke 2006-06-13 13:08:42 UTC
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.
Comment 31 Mark Wielaard 2006-06-13 13:20:04 UTC
All my test apps and this sudoku example look fine again.
Comment 32 Mark Wielaard 2006-06-13 13:27:10 UTC
(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.
Comment 33 Norman Hendrich 2006-06-13 13:29:43 UTC
(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.
Comment 34 Mark Wielaard 2006-06-13 13:34:56 UTC
Closed.

BTW. Hades looks very nice. Looking forward to the bug report and trying it out again :)