Problems in the time per frame when I move the mouse

I have a problem in my project. Normally when I run my project the time per frame is usually constant (60hz vsync enabled), has the following form:

TPF-approx 0016

TPF-approx 0016

TPF-approx 0016



But sometimes (not always the case, the first time I run does not usually happen)

when I move the mouse time per frame takes the following form:

TPF-approx 0030

TPF-approx 0001

TPF-approx 0030

TPF-approx 0001



only when I move the mouse (it happens even without listeners associated with the mouse). The funny thing is that if I press a mouse button while you move the time back to normal (as I have it down only).



This effect produces an unpleasant flickering image when you make a turn and strafe (FlyByCam + ChracterControl). In practice it is as if the execution rate is halved.



This problem occurs in JMonkeyEngine 3 Beta and downloaded the latest nightly build (jME3_2012-01-10.zip) in Eclipse and Netbeans JmonkeySDK.

i noticed the same issue (my OS is linux).

A few questions to try to narrow down what is happening:

-How are you limiting the frames to 60 hz? Just with vsync?

-To the original poster: is your OS also Linux?

-If in your update you grab your own System.nanoTime() and check the deltas, do they look similar or are they steady?

-and just to be sure, you have not overridden the Application’s timer in any way, right? Making sure we are all on the same page.

i just open a scene and set vsync.

nanoTime() is not used. I suppose i have this issue since nanoTime() was implemented… but possibly i’m wrong.

No, I’m suggesting using System.nanoTime() in your update to do an independent measurement. I’m trying to determine if tpf is wrong or if frames are erratic. For example, perhaps the mouse event delivery is somehow resetting time when it grabs tpf for itself or something. Just an odd ball speculation.



Knowing what the real time is doing would help eliminate some possibilities.

Hi All,



Working on mifth.

We have with “Vsync” enable a fix TPF to 16 (60 FPS).



If I use "System.nanoTime() " the TPF come to 13 (75 FPS).

We did not face exactly the same behaviour as “josel” with the mouse but the game is flickering too



We downloaded the latest nightly version. Never saw it before

Sorry for the delay. My OS is Windows Vista. I think it has to do with any Display.processMessages synchronization, the fact that I do not always occur, it is as if some process that remains after old executions and block this method, so I think.

I’ve been working on this issue I download the latest nightly build and I made a modification in the class LwglAbstractDisplay.runLoop:



[java]

/**

  • execute one iteration of the render loop in the OpenGL thread

    */

    protected void runLoop(){

    if (!created.get())

    throw new IllegalStateException();



    listener.update();



    // All this does is call swap buffers

    // If the canvas is not active, there’s no need to waste time

    // doing that …

    if (renderable.get()){

    assert checkGLError();



    // calls swap buffers, etc.

    try {

    if (autoFlush){

    //Enable vSync, realy must be if (settings.vSync == true) {…

    Display.setVSyncEnabled(true); // Equivalent Display.setSwapInterval(1);



    //Swap buffers without message processing

    Display.update(false);



    //For some reason vSync product some sychronize efects on Display.processMessages() in my System (Windows Vista)

    //Disable vSync for message processing

    Display.setVSyncEnabled(false); // Equivalent Display.setSwapInterval(0);

    }else{

    Display.processMessages();

    Thread.sleep(50);

    // add a small wait

    // to reduce CPU usage

    }

    } catch (Throwable ex){

    listener.handleError(“Error while swapping buffers”, ex);

    }

    }



    // On my test frameRate == -1

    if (frameRate > 0){

    Display.sync(frameRate);

    }



    if (renderable.get()){

    if (autoFlush){

    // check input after we synchronize with framerate.

    // this reduces input lag.

    Display.processMessages();

    }

    }



    // Subclasses just call GLObjectManager clean up objects here

    // it is safe … for now.

    renderer.onFrame();

    }

    [/java]



    Basically vSync is enabled only during swapBuffers, then turn it off for processing messages.



    This patch fixes my problems with flickering and oscillating framerate when I move the mouse … black magic … I do not see much sense.



    I think the real problem is that the application does not close properly, sometimes I can see in the debug view of eclipse that the application not completed but the window has closed.

    Some of these executions thread interferes with the current run, probably the previous patch minimize this situation. It’s just a hypothesis.

@pspeed , about our problem with flickering… it was solved. Me and @shirion investigated our problem was in our own API. In the update() . So, JME works ok in our case.



@josel did you try to switch Vsync on? Sometimes it helps and flickering disappears.

Yes, with vsync disabled the problem does not happen, the flickering in this case is different (is normal), but with vsync on flikering In some runs is very pronounced, due to the oscillation in the time per frame when I move the mouse.



In my case I can reproduce the problem with the most basic test for beginners in the web. Even with an empty project (SimpleApplication) writing time per frame in the update (), without any listener associated with the mouse. The problem usually occurs in the second or third time I run the program.



I only know that since I made the above modification the problem did not occur. At least I do not see the effects.