fps dependent of refreshRate?

Java 2D
#1

Hello,

I am, as many of you, working on my own framework. I experienced a strange behaviour with certain combinations of screen resolution, page flipping (in fullscreen mode) and monitor refresh rate.
To go into detail:

  1. when using resolution 800x600 Px, everything is ok.
  2. when using 1280x1024 in windowed mode (without page flipping), everything is ok,too.
  3. The problem occurs only in 1280x1024 in fullscreen mode, using pageflipping the usual way, using BufferStrategy.
    Then I get 77fps when running the monitor with 75hz, and
    only 26 (!) fps when switching to 60hz.
    Thats, of course, not nice because I cannot know what will happen on the users system.
    26 fps is not sufficient for the kind of game I have planned , so I have to find a way to get rid of this.
    The fps is not mainly influenced by the test animation I was using, as it makes no difference whether I push around 5 or 500 things on the screen, the fps in the problem case will not exeed 26.
    Has anybody heard about something similar?

Any help is appreciated.

Regards,
Frank

#2

Sounds to me like 1280x1024x[16 or 32?]x[how many buffers were you using, 2 or 3?] is more than the available vram.
So the backbuffer[s] were being shunted to main memory, and a blit strategy was being used instead - hence the dire framerate.

As to why the same thing isn’t noticed in windowed mode… dunno, are you running your desktop in 16bit, and were doing the fullscreen at 32bit?

#3

But he said: [quote]The problem occurs only in 1280x1024 in fullscreen mode, using pageflipping the usual way, using BufferStrategy.
Then I get 77fps when running the monitor with 75hz, and
only 26 (!) fps when switching to 60hz.
[/quote]
Same memory requirements, just a different (slower) refresh rate.

Very odd.

#4

Thank you for the fast answer, Abuse.

[quote]Sounds to me like 1280x1024x[16 or 32?]x[how many buffers were you using, 2 or 3?] is more than the available vram.
So the backbuffer[s] were being shunted to main memory, and a blit strategy was being used instead - hence the dire framerate
[/quote]
Checking the BufferCapabilities says that page flipping is on in every fullscreen mode, AFAIK this means that everything is in vram, as page flipping is done there.
Nevertheless I made some more test runs with different bit depths, all with a fullscreen 1280x1024 window with 2 buffers and got these strange results:

8 bit / 60hz : 61 fps
16 bit / 60hz : 25 fps
24 bit / 60hz : 67 fps
32 bit / 60hz : 68 fps

8 bit / 75hz : 79 fps
16 bit / 75hz : 79 fps
24 bit / 75hz : 75fps
32 bit / 75hz : 78fps

So, everything is fine exept when running with 16bit / 60hz…
This is making me sick.
Maybe the best workaround is to give the user the possibilty to change these settings himself, but many people will not be able to do that.

#5

oh yeah :slight_smile: damn i should read more carefully.

Are you changing to a different refreshrate at runtime?
BufferStrategy could be allocating vram for the back buffer, before deallocating the old vram - and perhaps running out.

Are you doing a tight loop on bufferStrategy.show(), with no sleep or timer delays , or anything that could cause you to miss frames.

To avoid all these guesses, how about u post your main loop :wink:

#6

hmm, looks like a bug in the 16bit render loops… or something :slight_smile:

whats your gfx card? windows version, jvm version, etc etc etc?

incidentally, What are you using to measure your framerate?

cos a vsync’ed page flipping strategy can never give a higher framerate than the refreshrate?!

I’m guessing the framerates you are quoting are incorrect due to currentTimeMillis() inaccuracy, not due to a weird timing loop you are using?

#7

This won’t be the Nvidia-with-broken-2D-drivers bug would it?

Cas :slight_smile:

#8

[quote]hmm, looks like a bug in the 16bit render loops… or something :slight_smile:

incidentally, What are you using to measure your framerate?

cos a vsync’ed page flipping strategy can never give a higher framerate than the refreshrate?!

I’m guessing the framerates you are quoting are incorrect due to currentTimeMillis() inaccuracy, not due to a weird timing loop you are using?
[/quote]
You may be right with the bug, actually I am using Jre 1.5.0 beta, I tried to use 1.4.2_3 a few minutes ago and in the problem-mode(16bit/60hz) appeared just a grey screen, while the program was running without reporting a bug. Other modes worked fine with 1.4.2_3, (at least the few I tried, I got somewhat tired of trying out all of them).
So, we are talking about a very new feature, which may be still in flow. Perhaps its a waste of time to think to much about this at the moment.

But, as you asked: I am using a P4 with w2k and a Matrox G550 card.

Here is the main loop:


while (mainThread==thisThread){
                  // Event Handling
                  currentGameScreen.handleEvent(null);
                  // moving objects, doing game logic
                  currentGameScreen.move(System.currentTimeMillis()-time);
                  time=System.currentTimeMillis();
                  // rendering to the screen
                  g=(Graphics2D)bufferStrategy.getDrawGraphics();
                  currentGameScreen.drawScreen(g);
                  g.dispose();
                  bufferStrategy.show();
                  totalNumberOfFrames++;
                  try {
                        Thread.sleep(5);
                  } catch (InterruptedException e) {
                        e.printStackTrace();
                  }
            }
#9

Matroxshudder :frowning:

This isn’t the 1st time a bug has been reported against matrox cards.
At the risk of sounding like a broken record, you should check for newer drivers.

However, if it works in a previous version, and is broken in 1.5 - its is worth reporting to Sun,
or atleast shout realy realy loud for 1 of the Sun folk who hang out here :wink:

#10

[quote]Matroxshudder :frowning:

This isn’t the 1st time a bug has been reported against matrox cards.
At the risk of sounding like a broken record, you should check for newer drivers.
[/quote]
Very interesting, will do so.

Again, you got me slightly wrong.(Consider using a Matrox card- these got very good text readability ;))
In 1.4.2 it was worse than in 1.5.

#11

oh thats nothing to do with my gfx card, im just a lazy reader :wink:

Still, 1.4 and 1.5 behaving differently is… interesting.
The 1.4 problem sounds like the ‘bufferstrategy creation failure’ bug from long ago.
This tends to happen when you have the createBufferStrategy immediately after changing to fullscreen mode.
The solution I believe was to add a sleep ot 2 inbetween the 2 lines. (or execute the fullscreen & bufferstrategy creation stuff in the event dispatch thread, EventQueue.invokeAndWait(Runnable))
If you can get it working properly in 1.4, and the same code doesn’t work in 1.5 you will help the engineers no end in tracking down the cause.
Same goes for if you can make 1.4 fail in the same way as 1.5.

#12

[quote]Thank you for the fast answer, Abuse.

8 bit / 60hz : 61 fps
16 bit / 60hz : 25 fps
24 bit / 60hz : 67 fps
32 bit / 60hz : 68 fps

8 bit / 75hz : 79 fps
16 bit / 75hz : 79 fps
24 bit / 75hz : 75fps
32 bit / 75hz : 78fps
[/quote]
In Fullscreenmode ( i think all these numbers are fps in fullscreen ) you are Limited to Refresh Rate means

FPS <= Refresh Rate

Anything above is quirks, in Windowed Mode you HAVE TO limit it by yourself ( Java has no bulit in support for Windowed Mode VSync )

If you can post your render code or tell us how it works ( if u cant do it because of copyright its ok ) otherwise try your java app on some other machines / hw configurations.