Timing problems

Java 2D
#1

This is related to a previous post, but I think sufficiently different to warrant a new one (because I’m seeing a larger effect)…

I was about to reply to No_Germs post about fillRect being quicker than drawImage when I realised that I am completely unable to perform reliable timings. For me (I’ve tested this on a few boxes), g.fill* or g.drawImage methods appear to take the entire screen refresh time - no matter how trivial they are. For example in a standard loop, the g.fillOval below


Graphics g =  bufferStrategy.getDrawGraphics();			
startTime = System.nanoTime();	
//g.drawLine(0, 0, 100, 100);
g.fillOval(0, 0, 10, 10);
endTime = System.nanoTime();
renderTime = endTime - startTime;
g.dispose();
bufferStrategy.show();

appears to take 1/refresh (refresh = 75Hz), i.e. renderTime ~ 13ms. However, the g.drawLine version results in a much, much smaller renderTime. I also get the same renderTime for a g.drawImage on a 4MB image, g.fillRect on any size rectangle etc… The fact that renderTime exactly equals 1/refresh for all these types of operations is too much of a coincidence - is there some synronization happening for all fill* and drawImage methods?

I have been hoping to interleave rendering with other expensive CPU operations, but am completely stumbled because I can’t reliably time g.drawImage (in my case).

Any hints?

#2

If you use only a few operations, lack of timing precision can cause lots of trouble. Have you tried drawing a few thousand frames, then taking the time? If the image is accelerated properly, framerates in excess of 500 should easily be obtainable on most computers (depending on image size, of course).

#3

Timing precision is fine - I get identical results if it runs all day. I’m talking about differences of 4-5 orders of magnitude between a g.drawLine and a g.fill* operation!!!

#4

So even if you scale the benchmark to thousands of successive calls to fill*, the results are identical? I don’t know much about Java2D and stuff, but I do know that some pretty funny things are going on. You mention yourself that the apparent link between drawing time and screen refresh rate is funny, but try filling thousands of rects right after another without show(), and see how it turns out. The operations might be grouped in funny ways.