JDK-7133527 : [macosx] Frame has minimal possible size with default layout and setSize()d child
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: os_x
  • CPU: x86
  • Submitted: 2012-01-26
  • Updated: 2012-04-17
  • Resolved: 2012-04-17
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 7 JDK 8
7u6Resolved 8Resolved
Related Reports
Relates :  
Relates :  
Relates :  
Description
Mac OS X macmini4,1
Run a regression test closed/java/awt/BasicStroke/DashZeroWidth.java
There, a Frame has a default layout without size set, and a Canvas is added which has no max/min/preferred size defined but just setSize(200,40).

With b224, it is displayed properly, 200x40+decorations size, and always pass (AFAIK). With b226, however, it has a minimal possible width (a few pixels) and height of decorations thus being virtually invisible. In this situation, the test fails more often than not.

Now, should it be fixed? If yes, it's a regression and priority should be bigger; if no, let's discuss specifications.

Comments
EVALUATION It looks like the issue is reproducible on one specific host only. We're unable to reproduce it on 5+ other systems running OS X 10.7. It seems that this is a PC-specific issue rather than a JDK issue, so I'm closing this CR as Not Reproducible for now.
17-04-2012

EVALUATION Reproducibility of the problem dependes on timings, so there must be a thread race somewhere. Most probably this issue may be related to the setVisible() call which re-dispatches the operation on the EDT. It may happen that the size set during the pack() call isn't yet seen from the EDT when actually showing the frame, and as such it gets assigned with zero size.
17-02-2012

EVALUATION This is only reproducible with local builds. If a build is run from a network location, the issue is unlikely to arise.
16-02-2012

EVALUATION Hmm, in fact, I've just reproduced it on my local macmini4,1 with Lion 10.7.3 without any VNC etc., on b11. Without disableCAlayers=true it failed for me as described once in 4 consecutive runs, and with disableCAlayers=true it fails as well but rarely. I had to start it 7 times.
16-02-2012

EVALUATION Note that there's still an issue with a frame that gets incorrectly sized, however, this is reproducible not in 100% of cases, and also got eased a bit with a fix for 7124553. We'll file another issue for this bug related to the frame size.
16-02-2012

EVALUATION The problem is reproducible when we run the test on Lion (10.7.3) machine remotely through VNC. One important detail is that a user other than the one who started the VNP connection should be logged into the machine locally. Otherwise, the problem isn't reproducible event after running the test remotely. Running with -Dsun.awt.disableCAlayers=true causes the problem to disappear. So, this issue might be a bug in the CALayer support or also this might be potentially caused by some kind of limitation with VNC.
16-02-2012

EVALUATION I'm unable to reproduce the case when a frame is invisible (in theory this may be somehow related to 7124553.) The frame always shows up on the screen. On 10.6.8 the dashed line is painted, and on 10.7.3 it is not. Looks like reproducibility of the issue is inconsistent. Also, an experiment shows that if I resize the frame on a 10.7.3 system, the dashed line finally appears on the canvas. Adding a print statement in the Canvas.paint() overridden method shows that it's being called once on both 10.6.8 and 10.7.3, so this doesn't seem to be related to delivering the PAINT event - it's delivered correctly on both systems. Running with -Dsun.java2d.trace=log produces identical output on both 10.6.8 and 10.7.3 as well.
15-02-2012

EVALUATION I run the test mentioned in the bug 7133527 on 10.7.3 and recent b11 promoted build, and observed two different scenarios: a) the test frame appears and has dimension according to the setSize() call (200x40) In this case, the test passes always. b) the test frame does not appears at all. In this case, jtreg kills the test by timeout, and reports a failure. I also tried b227 and b226: both of them shows the same behavior, although scenario b) happens no so often as in case of b11. So, I think that we should investigate an issue with the frame first, and only then run into investigation of problems with dash line rendering (it it will be needed).
14-02-2012

EVALUATION I've added the following line to the test right after it takes the screenshot: try { javax.imageio.ImageIO.write(img, "png", new java.io.File("/tmp/test-image.png")); } catch (Exception ex1) {} Then I examined the written image file. It appears that the dashed line doesn't get painted, and thus the test fails. Note that the image still contains a white rectangle which is correct - it is how the Canvas looks w/o the line painted. I've created the following simple test: import java.awt.*; import java.awt.geom.*; public class test { public static void main(String[] args) { Frame f = new Frame(); float[] dashes = {10.0f, 10.0f}; final BasicStroke bs = new BasicStroke(0.0f, BasicStroke.CAP_BUTT, BasicStroke.JOIN_BEVEL, 10.0f, dashes, 0.0f); Canvas c = new Canvas() { public void paint(Graphics g) { Graphics2D g2 = (Graphics2D)g; Line2D line = new Line2D.Double(20, 20, 180, 20); g2.setColor(Color.black); g2.setStroke(bs); g2.draw(line); } }; c.setSize(200, 40); c.setBackground(Color.white); f.add(c); f.pack(); f.setVisible(true); } } Basically, it emulates what the original test does. I've verified that on Mac OS X Lion (10.7) the test won't render the dashed line. NOTE: on Mac OS X Snow Leopard (10.6.8) the test passes w/o any issues. Therefore, this appears to be a Lion-related 2D rendering issue rather than an AWT bug. I'm reassigning the issue to a 2D engineer for further evaluation.
27-01-2012