• Type: Bug
• Component: javafx
• Sub-Component: graphics
• Affected Version: 8u60,9,10

• Priority: P3
• Status: Open
• Resolution: Unresolved

• Submitted: 2015-06-01
• Updated: 2021-12-18

Other
tbdUnresolved

As regression labeled and introduced in 8u or 9 -- targeted to 10 17-02-2017 Approved by component triage team to defer 16-08-2016 SQE: jdk9: OK to defer 16-08-2016 9-client-defer-candidate: There is no resources to fix it in jdk9. 15-08-2016 Attached a screencast video of the apps started by runcontrols.sh. 29-06-2015 SQE is ok to defer from 8u60. 15-06-2015 I didn't think my monitor was anything special. Here's the xdpyinfo output. screen #0: dimensions: 1920x1200 pixels (508x317 millimeters) resolution: 96x96 dots per inch depths (7): 24, 1, 4, 8, 15, 16, 32 root window id: 0xae depth of root window: 24 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x22 default number of colormap cells: 256 preallocated pixels: black 0, white 16777215 options: backing-store WHEN MAPPED, save-unders NO largest cursor: 256x256 current input event mask: 0xda4033 KeyPressMask KeyReleaseMask EnterWindowMask LeaveWindowMask KeymapStateMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask PropertyChangeMask ColormapChangeMask number of visuals: 20 default visual id: 0x20 visual: visual id: 0x20 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits 15-06-2015 Leif, what is your display resolution? Other than Ubuntu 15, that is the one other variable that could play here, as you have a relationship with Hidpi. None of my machines would come close to that. 15-06-2015 This particular symptom won't reproduce on 8u40. The reason there is disagreement about whether it is a regression is that the underlying bug is a race condition in the glass/gtk startup code due to the asynchronous handling of some of the window events. So technically, David is right that the underlying bug has been there all along. However, on Leif's machine there is a changeset introduced in 8u60 that exposes the bug, such that it reproduces in a reliable manner. Given that, I would agree with Leif that it is a regression on machines such as his that (for whatever reason) expose the problem. Regardless of whether it is or isn't considered a regression, if it only happens on one (or a small subset) of Linux machines it seems we should defer it. Perhaps David can continue to look for a safe workaround, but a fix for the underlying issue is out of scope for 8u60. 13-06-2015 Could someone try to reproduce it on 8u40? 13-06-2015 The issue started occurring after the fix for JDK-8098184, as indicated by hg bisect. My machine was not loaded, and I did not observe that startup was slower than before. The difference is that the window now shows junk instead of being blank. Why would this not be considered a regression? Hardware: Core i5-3317UU @ 1.70GHz × 4 Verbose output: Prism pipeline init order: es2 sw Using java-based Pisces rasterizer Using dirty region optimizations Not using texture mask for primitives Not forcing power of 2 sizes for textures Using hardware CLAMP_TO_ZERO mode Opting in for HiDPI pixel scaling Prism pipeline name = com.sun.prism.es2.ES2Pipeline Loading ES2 native library ... prism_es2 succeeded. GLFactory using com.sun.prism.es2.X11GLFactory (X) Got class = class com.sun.prism.es2.ES2Pipeline Initialized prism pipeline: com.sun.prism.es2.ES2Pipeline Maximum supported texture size: 8192 Maximum texture size clamped to 4096 Non power of two texture support = true Maximum number of vertex attributes = 16 Maximum number of uniform vertex components = 16384 Maximum number of uniform fragment components = 16384 Maximum number of varying components = 128 Maximum number of texture units usable in a vertex shader = 16 Maximum number of texture units usable in a fragment shader = 16 Graphics Vendor: Intel Open Source Technology Center Renderer: Mesa DRI Intel(R) Ivybridge Mobile Version: 3.0 Mesa 10.5.2 vsync: true vpipe: true 13-06-2015 Removing the regression tag - I really, really don't think that is the case. 12-06-2015 This is a timing/machine load issue. I tried this for a while on my dedicated machine, and also on my VMWare/Mac machine and did not reproduce the issue. That does not mean that I have not seen issues like this in the past however, but to put into context frequency of the issue. I also tried forcing the issue using -Dprism.order=sw and adding system load. Kevin said he had a similar difficulty replicating the problem. There are some core issues with GTK initialization that I would like to address in 9. Most of these are related to window size problems to remote displays, but past efforts to correct the problems have shown that unintended side effects are easy to create. Adding 8u60-defer-request 12-06-2015 are you still targeting to fix in 8u60 ? 10-06-2015 Downgrading to Major. This is a transitory issue that should resolve itself when the events catch up. Ugly but not fatal. 08-06-2015