JDK-6331736 : REG: KeyEvents triggered slowly
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 2005-10-03
  • Updated: 2011-01-19
  • Resolved: 2006-03-10
Related Reports
Relates :  
JDK-6236120 - SwingSet2:Shift-F10 shortcut key is not working to activate popup menu.
Description
Key events are triggered slowly in b51 compared to b50. This is noticed on XToolkit with Solaris and Linux.

Attached is a testcase to reproduce the problem. The testcase is automated. It presses a key and checks the time taken to trigger events. Also attached is the output log when run on b50 and b51 on Solaris.
Comments
EVALUATION you can specify a static timeout by setting env.variable _AWT_STATIC_POLL_TIMEOUT
10-03-2006
EVALUATION It is not a bug, it's feature, after all. Here's an excerpt from XToolkit.c: // AWT static poll timeout. Zero means "not set", aging algorithm is // used. Static poll timeout values higher than 50 cause application // look "slow" - they don't respond to user request fast // enough. Static poll timeout value less than 10 are usually // considered by schedulers as zero, so this might cause unnecessary // CPU consumption by Java. The values between 10 - 50 are suggested // for single client desktop configurations. For SunRay servers, it // is highly recomended to use aging algorithm (set static poll timeout // to 0). static int32_t static_poll_timeout = 0; As we can see, default timeout value is zero means "use aging algorithm". With given test, robot does press a button with a uniform delay of 500, and aging algorithm quickly and cleverly adapts to this behavior setting delay to 250, thus saving CPU time! Set (robot's) delay to 50 - poll will work faster. Now, I'm closing this bug. I understand there may be some inconvenience in testing routine: we should live with it; there may be real-world configuration issues: let's fix them on case-by-case basis.
10-03-2006
EVALUATION I cannot reproduce this bug on my Linux box. On old Solaris machine, some runs also have quite reasonable response time while some are slow. "Slow" means, some keystrokes take as much time to process as timeout set. In XToolkit.c is implemented aging algorithm requiring wakeup call - basically, writing of a byte to a certain pipe. The only routine calling wakeup instructions is awt_output_flush() from XToolkit.c, and it is only called from the native code; more presizely, from AWT_UNLOCK macro (awt.h) which is called mostly in 2D native code. In XToolkit.java there's awtFUnlock() function also invoking awt_output_flush(), however it is never used.
20-10-2005