JDK-8093560 : GTK application size wrong on remote X11 display.
  • Type: Bug
  • Component: javafx
  • Sub-Component: window-toolkit
  • Affected Version: 8
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2013-06-26
  • Updated: 2015-06-12
  • Resolved: 2014-10-20
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 9
9Resolved
Related Reports
Relates :  
JDK-8088236 - GTK requested size failure on remote display
Relates :  
JDK-8094564 - [HelloTextArea, Ubuntu] Window comes up razor thin instead of a "nice size"
Relates :  
JDK-8089473 - GTK - multiple resizes on remote X11 display
Description
I am using Linux displaying a JFX application onto a remote X11 display on a Mac.

The application requested size will always show correctly on the connected local display (:0) but will always be wrong on my remote display. The presented size appears to be a minimum  based on the title size by maybe 10 pixels tall.

If I resize the window - the displayed contents look correct.

Other X11 applications do not appear to have this issue.

I suspect that this is a flaw in our handling of X11 window sizing in glass, that we are creating a minimum sized window, and cannot properly handle the delay in X11 server response to the subsequent window sizing.

Tested with a number of applications, but most recently with toys from HelloWorld.jar, helloworld.HelloSanity, and helloworld.HelloRectangle

Last note: using SSH forwarding.
Comments
marking this dup of the new tracking bug.
20-10-2014
reverted
20-10-2014
Reverted - and has a new bug (RT-39050) GTK requested size failure on remote display
20-10-2014
Close this JIRA?
07-10-2014
+1
07-10-2014
Pushed changeset: 58cd55dbc9f7 Testing was done with multiple Hello apps, in particular HelloWindowManager, HelloSanity, HelloRectangle over a remote display (using ssh -X to the Linux Host).
07-10-2014
+1 as for WindowContextPlug and WindowContextChild they are used in JavaFX web applets.
03-10-2014
Sounds reasonable. This proposed fix tested fine on my system.
02-10-2014
One other note - I am still not happy with the number of resizes when starting HelloRectangle. I see 2 incorrect notify calls before we settle on the proper size. I can see this in the rendering of the app too (HelloRectangle). That issue will be in a follow on Jira.
02-10-2014
Chien - there is other calls of a similar pattern, that I did have changes on, but I removed them when I did not find them in the path of my startup. I used HelloSanity/Windows and HelloWindowManager to try stage & child popup windows and those seem to be OK with this change. Given my newness with this code, I went with "path of least change". (Especially as I seem to be one of the few complaining about the issue).
02-10-2014
I'm not familiar with this part of the code. It seems to do what is described for the fix in the process_configure method. What about other process* methods that have similar "CallVoidMethod(jview, jViewNotifyResize" call?
02-10-2014
webrev at http://cr.openjdk.java.net/~ddhill/RT-31306 The idea is do delay some resizing actions until we are mapped on the screen. Without this, a linux app run over ssh -X would show up with a minimum size as the intermediate size over road the requested size.
01-10-2014