> > > > and the current code *does* go through a BufferedImage. > That's what I figured... I'd recommend redoing it without. >
DO NOT. I happened to be around to chat with the author of that code - Scott Violet, at the time one of the lead developers on the Swing team, when he rewrote that component - this was around the time of the defunct Swing Application Framework JSR, and being friends with a few guys on the Swing team, hung out in their offices in Santa Clara a good bit. The reason: GradientPaint's allocate large rasters (large being int[width * height * 4]) on every repaint. That creates a ton of GC pressure and memory churn from something that's repainting itself on a timer, for absolutely no reason. The solution: Keep an offscreen BufferedImage with the gradient, which only ever needs to be painted *once*, and then clear area that was *not* the graph. A solution I suggested to Scott, who said (with an unspoken trailing "you idiot") "Yeah, that's what I just wrote." Anyway, it's like that for a very legitimate reason. If there are scaling issues, try using (on the component) getGraphicsConfiguration().createCompatibleImage(width, height) (and if you want to be anal about it, keep track of the GraphicsConfiguration and recreate it if it changes [window was moved to a different size monitor]) - or if creating it independent of component creation, GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration().createCompatibleImage(width, height) (but don't expect it to necessarily be right in a multi-monitor setup). Most likely the root of the problem is simply theGraphics.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING, RenderingHints.VALUE_ANTIALIASING_ON) At any rate, it is using an offscreen BufferedImage for a very good reason, and I'd strongly recommend not ripping that out unless you want to cause a completely pointless performance issue. -Tim
