Input lag

[spasi]

Ah btw, calling processMessages multiple times per frame should be harmless afaik.

[basil]

cheers

.. no I think the way its done now is pretty good. Lag is reduced only by ~5ms in my case doing method A.

There is probably just one pitfall left about input lag.

with vsync off this works good but may still bug people when using Display.sync() or similar with vsync off.

good:
method C

Code:

while ( run ) {
    Display.processMessages();
    handleInput();

    render();

    Display.update(false); // swap buffers without input processing
    Display.sync(10);      // proper sync
}

bad :
method D

Code:

while ( run ) {
    handleInput();

    render();

    Display.update(); // swap buffers with input processing
    Display.sync(10);
}

good (probably ?) :
method E

Code:

while ( run ) {
    handleInput();

    render();

    Display.sync(10); // almost proper sync
    Display.update(); // swap buffers with input processing
}

i keep it mixing up all the time

[basil]

btw, 2.4 works way better for me in general.

fullscreen + org.lwjgl.input.Mouse.setGrabbed ( true ) finaly works realy good

.. maybe its just my setup .. but does AWT canvas rendering (Display.setParent()) work with grabbed mouse now as well ?

[spasi]

Good point there, I've added the processMessages flag in Display.update(). The default will be true for existing code.

Also tried mouse grabbing with canvas and it works fine (in an applet even).

[spasi]

Btw, some vsync issues seem to be related to NV's threaded optimization on multi-core machines. You may want to check your code both with and without threaded optimization (there's an option to disable it on NV's control panel).

[basil]

thanks again

was wondering what that thread optimization is doing anyway ...

.. to confirm canvas grabbed mouse, indeed it works.

in my case, I got a 2nd JFrame up with some text stuff scrolling around. once closed, mouse behaves just right. before that the OS cursor is drawn onto the canvas center only when 2nd frame does write text.

looks like some AWT canvas <-> swing <-> whatnot <-> paint()/focus() trouble. swing setIgnoreRepaint() nor setFocusable() do help here. anyway, thats fair enough.

[basil]

btw .. again, and to hijack this thread completely :

not using grabbed mouse but Mouse.setNativeCursor() with that setup makes the new cursor flicker as well .. but works with a 'single JFrame canvas'.

no difference with or without NV thread optimization.

[spasi]

Any chance you could send us a test case that reproduces this problem?

[basil]

aye,

here's a little quick'n diry draft.
http://kinoma.highteq.net/stuff/slimLWJGL.7z

and the netbeans project without the lwjgl-2.4 lib, you'd have to fix it by yourself if you want to.
http://kinoma.highteq.net/stuff/slimLWJGL_netbeans.7z

its windows set, but should work with linux/mac (-Djava.library.path=bin/[...] )

.. it 'should' show the flickering cursor with grabbed mouse , the native cursor flickering and the funny resize bahaviour when Display.update() not used properly.

[HerrKhosse]

Am still having trouble with enabling VSync.
My rendering loop looks currently like this:

Code:

while (!Display.isCloseRequested()) {
input.checkInput();

gfx.drawGL();

Display.update(); // swap buffers without input processing
Display.sync(480); // proper sync

updateFPS();
}

as long as I don't enable vsync, this works perfectly, I still use the HWCursor, but there is almost no lag.
Problem is, whenever I enable vsync, I get the reported ~35ms Input lag, tried several ways, always the lag.

I'm trying to make something like a 2D RTS, so when scrolling, you can see alot of v-line issues without vsync.
It's obviously possible to use vsync without having input lag, I'm just interested if this can be fixed without looking alot in the subroutines of the procedure and trying to fix it