This content has been marked as final. Show 7 replies
This affects our applet too and I have been investigating. I have put a summary of my findings on my website here: http://www.chrisnewland.com/applet-graphics-corruption-in-java-7-update-10-on-mac-osx-309
It is related to the size of the applet and is 100% reproducable. I have submitted a bug report but that is still in review (ID 2406665).
It looks like Java 7 update 10 broke the way memory is used for double buffering in applets and if the applet is bigger than the browser height then this corruption occurs.
Thank you. That helps a lot. Since update 9 seemed to cause problems with webstart I had been focusing on trying different methods to start it. It never occurred to me to try changing the size. Although with a smaller size I'm still getting random graphics artifacts(short red lines and dots through out as well as combo boxes that don't show up and tabs where the text shows but not the tab), but it still requires scrolling so I'll try opening it in a page by itself to avoid any scrolling and see if it looks more normal. This applet is using double buffering because its drawing genes, heat maps, sequences that users can zoom in and out and navigate so it just didn't look great without double buffering.
Everything that you describe seems to fit with what I'm seeing. Thank you for figuring it out and submitting a bug report. I hope they'll fix it soon.
I'm seeing the exact the same issue. If the applet is larger than the browser screen the content gets shifted down by about 400px and the top is random garbage from the video buffer. Some of our users found that using the Zoom In/Zoom Out commands can get the applet to render at a size that is usable. Obviously it's not ideal.
We've seen it on 10.8.2 using Java 7u10 and 7u11. I tried disabling double buffering using the RepaintManager on the JApplet but it doesn't seem to help.
I got around the problem by shrinking the size of the applet and adding a scroll bar (i.e. a JScrollPane). It looks pretty ugly but it is better than an unusable applet.
I think the problem is related to the Java plugin loading animation. If you clear your cache and go to a page with an applet, you can reject the applet (don't allow it to run) and you'll see a blank square at the top and the rejected applet under it. It looks like the blank square is where the loading animation should have been but for some reason it isn't rendering (or rendering random garbage from the video buffer) if the applet would scroll off the bottom of the browser window.
I too am having the same problem.
It appears to be related to the applet size parameters.
If you applet is less than 1152x864 I do not see the corruption. Once you pass some magic size, it really looks like the top or origina of the back buffer is pointing to the wrong spot (some bad pointer math).
For me some of the corruption includes the data from the java console I have up trying to debug. The bottom of the applet is also clipped. I have not been able to verify the size of how it is clipped but it is that fact plus the corruption at the top that makes me think the back buffer pointer is just wrong.