JDK-6331762 : REGRESSION: Wrong FontMetrics set when painting custom components in JScrollPane
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2005-10-03
  • Updated: 2010-09-29
  • Resolved: 2005-11-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b60Fixed
Related Reports
Relates :  
JDK-4967886 - Swing should provide full double buffering per window
Relates :  
JDK-6307484 - Problem with font in NetBeans
Description
A component with custom renderer placed in JScrollPane is being passed a Graphics object with incorrectly initialized FontMetrics during scrolling. Standard paints get correct FontMetrics, paints initiated from scrolling operations don't. I'll attach a simple test case that demonstrates the problem. It works correctly on JDK 1.4.2 and 5.0. It fails on Mustang.

This seems to be the root cause of NetBeans bug #51731:
http://www.netbeans.org/issues/show_bug.cgi?id=51731

first time reported against Mustang b13, reliably reproducible since then until b53.

The same bug was reported against Mustang as #6307484. Closed as 'not reproducible'. I believe that the attached test case points to a Mustang issue.

---

The attached test case shows a JFrame containing a standard JList with a custom cell renderer. Custom font is set to Monospaced, 11pt. The initial paint works ok. The problem occurs when I start to scroll the JList content using the scroll bar. The debug getFontMetrics() dump shows that different FontMetrics are being passed in the "standard" and "scrolling" scenarios.
Comments
EVALUATION Last suggested fix wouldn't address the real problem, in that the Graphics supplied to paint is effectively ignored. New fix is to modify paintForceDoubleBuffered (JViewport calls this) to call into the RepaintManager which will callback to paint with the right Graphics.
05-10-2005
EVALUATION This is the result of the gray rect work. Prior to this when we scrolled we would do the following: A. turn off double buffering at the RepaintManager level. B. Get the Image from the RepaintManager. C. Get graphics from it. D. Invoke paint on component The test previously worked because step D would end up creating a new Graphics and set the font it. The new code does: 1. Get the graphics from the component. 2. Invoke a package private method that makes us go through RepaintManager for painting to an offscreen image. 3. RepaintManager gets Graphics from offscreen image. 4. Invokes paintComponent/paintChildren back on component The test doesn't work now because step 4 is using the Graphics from the offscreen image which doesn't have the Font that was set. Proposed fix is to set the on the Graphics obtained from the offscreen buffer to the Font from the supplied graphics.
05-10-2005