found a bug. is it new?

Java 2D
#1

sorry if this has already been posted. and if not, i dont know how to file a bug report.

something in 1.5 (havent tested 1.4) causes an app to draw over the screen if the java program is terminated from the dos box using control - c (or closing the dos box) if it is in the middle of drawing onto a canvas. havent tried this with anything but canvas.
here’s a screenshot of what happens and the source so you can check it out yourself.

screen: http://www.adam.com.au/kellyjones/picsused/canvasSpill.gif

http://www.adam.com.au/kellyjones/java/CanvasTest.java – has main
http://www.adam.com.au/kellyjones/java/TestShape.java – something to keep track of a shape.

i think it might be because between killing the window and actually terminating the program, the paint method probably gets a few calls in…

edit – this is a basic test app i was messing with. it doesnt use bufferstrategy or anything. just draws onto the component. works with JPanel as well, so it’s not a canvas issue but a Component issue.

#2

hehe, cool :wink:

I get the same effect here.

1.4.2_03 gives the same results too.

Pro’lly due to Windows interpreting a blit to hdc 0 (null) as a blit direct to the screen.

#3

i wonder is there any way we can mess with this to let us blit direct to the screen (as opposed to an accident caused by unexpectedly killing an app)

would be quite interesting… though utterly useless for anything but a timewaster app… (u know, those things where you can trash your desktop…)

or maybe for lectures where a lecturer is (heaven forbid) using something other than powerpoint and wants to be able to draw all over the screen while he’s showing this PDF or whatever…

or you have a public pc at an internet cafe and the owner wants the PC to display the company logo at the top-mid of the screen (regardless of what program the user is running)

or… you want a splash screen that is not square (though even adobe dont seem to have worked that one out yet).

though trying to tell the OS that it needs to redraw the area you grafiti’d would be a dificult task.

#4

hehe, i thought exactly the same thing; ‘how can we exploit this bug to get non-rectangular windows’ :smiley:

hang on… what happens if you grab a graphics context to w window, store it, then dispose of the window?

I guess any subsequent calls to the Graphics object will cause an IllegalStateException? or maybe they won’t :stuck_out_tongue:

/me trundles off to test.

:edit:

ok, how about using a finalizer to grab the Graphics Context that draws direct to the screen - and then passes it to a daemon Thread.

:edit:

or… how about simulating what happens when u ctrl+c the JVM, by killing the awt thread with a Thread.stop().

#5

did a little benchmark - and it is a little more than ‘the paint method probably gets a few calls in.’

with this code :-

Between the time the window is killed, and the application Thread is terminated, I get approx. 11000 fillRects in! (worked out exactly how many by measuring the area of the screen covered by the red)

1152×864 70 KB

import java.awt.*;
import java.awt.event.*;
public class BugTest
{
   public static void main(String [] args) throws Exception
   {
      Frame f = new Frame();
         
      f.setBounds(0,0,500,500);
      f.show();
      Graphics g = f.getGraphics();

      g.setColor(Color.red);
      while(true)
      {
         for(int y =0;y < 768;y+=50)
         {
            for(int x = 0;x < 1024;x+=1)
            {
               g.fillRect(x,y,100,50);
            }
         }
      }
   }
}

I’m not entirely sure what is happening, because if you reduce the area of the fillRect to much less than 100x50, the corruption goes away altogether.

Definitely a Thread race of some kind - but the duration of the native fillRect call seems to make a difference as to whether the corruption occurs or not.

Perhaps the JVM avoids interrupting the Thread while it is in the process of invoking a native method?

Also worth noting, the origin when blitting onto the screen is screwed up - perhaps this is because the Graphics context was originally intended for blitting onto a decorated frame, so would have its offset set to the width&height of the frames decoration.

#6

hmm, whatever happens to the Window, doesn’t happen in the finalizers. (I added a while(true) shutdown hook to prevent finalizers from ever executing - the result was, the window died normally - no corruption)

So, my guess is the cleanup for the Window is done either in (or before) the shutdown hooks are executed.
If we can isolate where abouts the Window is cleaned up (and made so no further corruption can occur), and can disable the Thread that performs this clean up - we should be able to get a stable Graphics context for drawing onto the screen directly :slight_smile:

btw, any1 know what is the difference between Ctrl+c’ing a JVM, and System.exit()'ing it is? :-/

The javadoc makes it sound like they are both handled the same way - but obviously this isn’t the case, as 1 causes corruption, the other doesn’t.

#7

The main problem here being:

how to tell the OS that it needs to clean up the area where you have done the equivelant of grafitiing it?

for splash screens, this would not be a problem cause your main app window would more than likely cover it up. (tho imagine a app being under the logo when it is drawn, you move the app, the logo would come with it)

#8

im sure System.exit() would be avoiding interrupting native calls of course, but ctrl + c (which is a DOS thing to kill just about any old dos app, and works in unix too) would probably be a native call itself and similar to the windows “End process” dialog…
you should try using javaw to display your bugtest and using the windows task manager to kill javaw and see if that produces the same result. i think it should.

anyway, gotta go to my next class. i hate having uni on 2 diferent campuses… did my timetable too late and now there’s too much travel

#9

That’s cool. Definitely a bug. I thought we’ve fixed something like this some time ago. Apparently, not…

I’ll file a bug tomorrow…