While working on developing an off-screen renderer which uses page-flipping, I encountered an unexpected behavior where calling:

Component.setIgnoreRepaint( true )

on the rendering target would prevent Ruby from dispatching calls to repaint(). To elaborate, the renderloop code repeatedly requests to repaint the rendering target (or the "surface") at no more than 60 frames per second. In order to keep track of page flipping (and performance) the surface internally tracks its current frame number.

So long as setIgnoreRepaint() was set to true, all Ruby-side invocations of the repaint() method would terminate before being processed and no frame number was incremented. This appears to have affected the initial painting of the surface as well, despite that being an AWT invocation.

When the method call to setIgnoreRepaint() was commented out or set to false, all repaint calls completed successfully, evidenced by the incrementation of the frame counter.

The current behavior appears to be in defiance of that stated in Component.setIgnoreRepaint(), reproduced below:

 public void setIgnoreRepaint(boolean ignoreRepaint)

Sets whether or not paint messages received from the operating system should be ignored. This does not affect paint events generated in software by the AWT, unless they are an immediate response to an OS-level paint message.

This is useful, for example, if running under full-screen mode and better performance is desired, or if page-flipping is used as the buffer strategy.

Identified while using jruby 1.7.13 (2.0.0p195) 2014-06-24 43f133c on Java HotSpot(TM) 64-Bit Server VM 1.8.0_05-b13 +indy [Windows 7-amd64]