Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
8303950: avoid letting Window.paint(..) call g.fillRect(..)
When Window.paint(..) calls g.fillRect(..): sometimes this results in flickering. The problem appears to be that the monitor refreshes shortly after the call to fillRect(..) but *before* the RepaintManager has a chance to paint its replacement image with AlphaComposite.SRC. This proposal uses a new RenderingHint to tell Window.paint(..) to skip its paint method. This feels hacky, but I don't see a simpler solution at this point. (I can think of at least two hackier approaches though, if we want to brainstorm alternatives.) If there is a simple way to safeguard the monitor from refreshing prematurely that might be a much better solution, but I'm not familiar that logic. Skipping g.fillRect(..) should be safe in RepaintManager's case, because the RepaintManager is already calling: ``` g2d.setBackground(c.getBackground()); g2d.clearRect(x,y,bw,bh); ``` So in this bug's test case: c will be a `JRootPane`. And JRootPane's `getBackground()` method will default to the Window's background color. So we're already flood filling RepaintManager's buffer with the correct background color (which is the window's background color). And (sigh) in the event the JRootPane and Window have *different* background colors: the JRootPane "wins", and the Window's background color is ignored. This is weird (and maybe bad), but this is the preexisting behavior. If you set up a window with a background of `new Color(255,0,0,200)` and a JRootPane with a background of `new Color(0,255,0,200)`, then (when there is no flickering): the JRootPane's background color always wins and there is no sign of the red. IMO this is a very low-priority bug of its own, where the expected behavior is the JRootPane's background renders on top of the Window's background.
- Loading branch information