Swing buffering / window switching bug

Java 2D
#1

Has anybody else noticed Swing restoring from the wrong portion of the backbuffer if it isn’t the foreground application? This seems to be Windows only (OS X has a real back buffer now.) but if I drag a window in front of my applet I can see it restoring content from the origin of my window rather than the portion that needs to be repainted.

Anybody else run into this? I can’t seem to catch it as it messes up. My partial hack has been to force a repaint on paintImmediately if I’m not in the foreground (also a hack since an applet can’t check if it is in the foreground) but it still nails me with an incorrect redraw shortly after my window becomes frontmost again.

It would be a major pain to post all the code involved, just hoping maybe one of you had seen this and found a solution.

changed title to be slightly more descriptive

#2

YES. I’ve seen it many times. I suspect it is someting to do with Direct Draw acceleration code that is running behind the scenes… like blitting from a volatile image that lost it’s contents.

#3

Here’s a somewhat better description of the problem. It only happens when using Swing componenets in the applet.

I select a window other than my applet and drag it across the applet. As I do this the plugin seems to be accumulating dirty rectangles of the obscured areas. Then I select the applet window and it comes to the front. After a short time (but often AFTER my next repaint) the plugin copies from the origin of the back buffer into the collected dirty area. Thus if I’ve dragged over the applet window origin it flashes, but is ok, otherwise it draws misaligned junk.

I’ve tried every method I can think of to validate or invalidate the stuff from the Java side AND I’ve tried invalidating the Windows window that contains the applet from a JNI call, but nothing seems to fix this. If anybody has a solution to this I’ll be eternally grateful and/or bribe you in some way. It’s driving me nuts.

#4

Your problem sounds similar to the one in this thread:

http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=2D;action=display;num=1087912718

Are you transforming the graphics context in your code?

#5

No, that thread was about me being dumb. :slight_smile:

What I have seen is graphics from some completely different component - I think sometimes even including data from non-java windows that gets blitted into a dirty region.

BTW… has anyone noticed components not painting at all in low-memory (Java heap, not system) situations? I have a UI that starts to not paint components at all and the CPU usage skyrockets if the heap usage approaches 64MB… This happens when I am blitting a large NTSC-video size image or two. I get the feeling that it is stuck in a loop trying to get a volatile image’s contents to stick.
Oops… didn’t mean to thread-jack.

#6

I thought it was the transform, as I am setting it. However I am restoring it everywhere it gets changed and I still see the problem even if I comment out anything that even looks like a transform. It might be this bug, or a variation thereof:

Redraw problems when moving window over Swing component

I haven’t seen it stop painting completely yet, but I look forward to it. :stuck_out_tongue:

#7

May be a driver issue? Never noticed that so far…