I've been tracking down an extraordinarily strange bug all day, and i finally tracked down what it is, but I'm not sure if there's even a way to fix it. The problem, in a nutshell, is this: All input seems "lagged," as in it takes about a half a second between the time that i press a key or move the mouse, to the time that the program recognizes the input. I'll make a note here and mention that i'm using a Frame dedicated to exclusive fullscreen through the default graphics device. It's not my code. This bug didn't crop up until i started exporting to .jar files and testing things out-of-editor. It happened in every machine i tested it on, but never in the editor. After tearing my hair out, i tracked it down to that my Eclipse uses JRE 1.6u3, while the executable defaults to jre6 (latest update). Using the older jre, the input is snappy and normal. When using the latest one, input is slow and unresponsive, and even "hangs" for entire seconds at a time before getting cycled over to my program. So, at last, my question is this. What changed between 1.6u3 and 6u13 to make input act so wildly out-of-focus? And, more to the point, what can i do to make this work? I'm guessing the AWT event dispatch thread changed somewhere, but i can't find any info on it, or what to do even if that is the case.

In short, NFI.

I can't imagine this being a widespread problem - it's the sort of thing the industry would ditch Java for altogether, if it weren't resolved. I definitely can't replicate the problem, none of my jars have ever shown any actual GUI lag symptoms.

Assuming 1.6 is fancy internal-dev talk for Java SE 6, your Eclipse is about 13 u's behind the cutting-edge. There are plenty of deprecated methods in the GUI libraries - maybe you should update Eclipse, load up your project again, and see if any of your AWT calls have lines through them?

Otherwise, can you replicate the problem in a sample project, and provide that sample here?

Quote:Original post by Fenrisulvur

your Eclipse is about 13 u's behind the cutting-edge.

Eclipse has nothing to do with JVM. But the JVM running IDE, as well as the one running applications are chosen from system settings.

Quote:It's not my code. This bug didn't crop up until i started exporting to .jar files and testing things out-of-editor. It happened in every machine i tested it on, but never in the editor.

It's almost certainly your code, or better yet, the problem that existed was just now exposed, for whichever reason. How are you handling the input?

Quote:How are you handling the input?

Window is created, fullscreened at startup.

-"InputManager" object is created and registers itself with the window as a keylistener, mouselistener, and mousewheellistener (for motion, i poll on a per-update basis with mouseinfo)

-- Every time input is fired, the inputmanager (via AWT thread) throws condensed information about the event into an "InputQueue", which is really just a bunch of arrays with events stored in them.

--- Every logical update, the main thread runs down all the collected input and acts upon it.



I know you're thinking "well obviously it's a synchronicity issue with the inputqueue, or he gets terrible framerates" but it isn't. The program updates and renders as speedily as ever, and i didn't implement the InputQueue until after the problem started happening (i had thought i was loading down the AWT thread, so i offloaded to main thread).

Quote:Assuming 1.6 is fancy internal-dev talk for Java SE 6, your Eclipse is about 13 u's behind the cutting-edge. There are plenty of deprecated methods in the GUI libraries - maybe you should update Eclipse, load up your project again, and see if any of your AWT calls have lines through them?

Did, after i realized it was happening based on which JVM was running, i put 6u13 as the editor's standard JVM, updated the JDK and Eclipse. Nothing's deprecated (i'm not using anything exotic anyway, just the basic input listeners).


I'll see if i can throw together a stripped-down example of what's happening.

Are you sure other threads are yielding so you can run the control events?

Found it, had to do with a background image loader thread which apparently had more priority than it used to; it was delaying the AWT thread but not the main one, even though it only cycled once every ~50ms. Increased the delay between image loads and the problem went away.

I guess somewhere between 6u3 and 6u13 they gave program-created threads precedence over AWT.