JDK-7023013 : Hw/Lw painting artifacts
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 7
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2011-02-28
  • Updated: 2019-03-23
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-6778882 - InternalFrame within glass pane goes below a heavy weight component
Relates :  
JDK-6826074 - JScrollPane does not revalidate the component hierarchy after scrolling
Description
After fixing #6826074 there are still a few issues with painting hw components inside Swing,
please see the attached image with a cropped JButton.

It is believed that now Swing correctly validates the components after moving/resizing
so this is addressed to AWT.

Please use the test from 6826074 and 6778882

Run the test case from 6826074, scroll the JScrollPane back and forth
and see the painting artifacts on the button.

Reproduced on the latest JDK 7.
Comments
- this is an issue reported against 7(7u), - there are now affected version 9 filed for this issue - 7u issues are transferred to Sustaining Nevertheless if someone have a report against 9 - please reopen and add affectedVersion 9 or 7u specific escalations might be reopen to Sustaining
10-08-2014
- this is an issue reported against 7(7u), - there are now affected version 9 filed for this issue - 7u issues are transferred to Sustaining Nevertheless if someone have a report against 9 - please reopen and add affectedVersion 9 or 7u specific escalations might be reopen to Sustaining
10-08-2014
These are all approved for deferral to JDK 9 so you can update the FixVersion to state JDK 9. Kind regards, Mathias
29-08-2013
These are all approved for deferral to JDK 9 so you can update the FixVersion to state JDK 9. Kind regards, Mathias
29-08-2013
These are all approved for deferral to JDK 9 so you can update the FixVersion to state JDK 9. Kind regards, Mathias
29-08-2013
Converted "8-client-defer-candidate" label to "8-defer-request" by SQE' OK.
15-08-2013
*This is anti-deferral criteria list*: - P2 -------------- Engineering's Criteria ------------------------------------- - tck-red labeled - conformance labeled - P3 regressions reported/labeled against jdk8 - findbugs, parfait, eht labeled bugs - CAP <1 year reported - netbeans <1 year reported Victor ----------------- SQE's OK --------------------------------- Yes, we are ok with that thanks, Mikhail
15-08-2013
8-defer-request: This is the issue from 7 GA when it was approved to defer that time. Requesting to defer again because there are no customer escalations on this issue.
14-06-2013
EVALUATION Note that for windows7, not only -Dsun.java2d.noddraw=true eliminates the problem, but any change in default double buffering settings has the same effects, disregard enabled d3d pipeline or not. Also, quite similar problem can be reproduced on linux, with following combination of properties: -Dswing.bufferPerndow=flase -Dsun.java2d.opengl=True So, it looks like that an influence of swing double buffering need to be investigated, hence I am re-dispatching this CR back to swing.
08-04-2011
EVALUATION It's been verified that it's not reproducible with -Dsun.java2d.noddraw=true. Looks like it's a d3d-specific problem, transferring to java2d for further evaluation.
21-03-2011
EVALUATION 6826074 is not integrated yet. We need to get this fix from Swing prior to evaluating the issue with the AWT repository.
14-03-2011
EVALUATION Reproduced on linux only. Not on Windows.
01-03-2011