Many external developers complain about translucent windows performance, for example:

http://www.miginfocom.com/blog/?p=30
The current implementation of non-opaque windows in AWT/Swing is ugly. Here is a rough sequence of events for *every* user- or system-triggered repaint:

1. Repaint request is registered by Swing (RepaintManager).
2. Somewhen later, RepaintManager processes all the dirty regions - see RepaintManager.paintDirtyRegions().
3. All the dirty components in non-opaque windows are removed from the list to repaint, and the corresponding windows are updated with Window.updateWindow(null) call - see RepaintManager.updateWindows().
4. updateWindows(null) forwards to peer.updateWindow(null) and then to TranslucentWindowPainter.updateWindow(null).
5. As the given image is null, the latter method calls window.paintAll() to get the whole window contents.

See attached test to reproduce the problem. It shows a frame with a JButton and JTextArea at the bottom. The button changes window's opacity on and off, and text area prints all the upcoming paint() calls to the console. Launch the test, press button, observe the window gets non-opaque. Move the mouse over the button to trigger hover effect. If you see the text area is repainted on button hover, the bug is reproduced.