JavaFX embedded in jme3

javasabr · July 6, 2014, 11:24am

@Empire Phoenix said: Can you send your test class?

http://ideone.com/vx4F8m

Empire_Phoenix · July 6, 2014, 11:59am

Hm interesting, I don’t have that offset, but i have one large at the Menu in the upper left.

@abies might that be related to the popup capture thing?

javasabr · July 6, 2014, 12:51pm

@Empire Phoenix said: Hm interesting, I don't have that offset, but i have one large at the Menu in the upper left.
@abies might that be related to the popup capture thing?

You can make a screenshot of the popup? and you what version of java?

Empire_Phoenix · July 6, 2014, 2:06pm

What os are you on? I’m using linux.

empire-z86% java -version 
java version "1.8.0_20-ea"
Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b21)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b20, mixed mode)

javasabr · July 6, 2014, 2:13pm

@Empire Phoenix said: What os are you on? I'm using linux.
empire-z86% java -version 
java version "1.8.0_20-ea"
Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b21)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b20, mixed mode)
Imgur: The magic of the Internet

what may be possible causes of this problem?
OS: Ubuntu 14.04
Java: Java™ SE Runtime Environment (build 1.8.0_05-b13)

Empire_Phoenix · July 6, 2014, 2:32pm

Hm apparently the popups are at the wrong position, maybe the popupsnapper must use different offsets based on os?.

javasabr · July 6, 2014, 4:02pm

@Empire Phoenix said: Hm apparently the popups are at the wrong position, maybe the popupsnapper must use different offsets based on os?.

where in the code can determine the position popup?

abies · July 6, 2014, 6:07pm

Please look into JmeFxContainer.constructor. There is a piece of code like:

final int x = Display.getX() + (Display.isFullscreen() ? 0 : 3);
final int y = Display.getY() + (Display.isFullscreen() ? 0 : 25);

Please play with values of 3 and 25

#define 3 10

If this helps, then we will have to look into some reasonable way to find out window borders depending on OS - either through lwjgl or maybe even AWT, assuming it is normal OS decorated window.

javasabr · July 6, 2014, 7:34pm

@abies said: Please look into JmeFxContainer.constructor. There is a piece of code like: [code] final int x = Display.getX() + (Display.isFullscreen() ? 0 : 3); final int y = Display.getY() + (Display.isFullscreen() ? 0 : 25); [/code]
Please play with values of 3 and 25
#define 3 10
If this helps, then we will have to look into some reasonable way to find out window borders depending on OS - either through lwjgl or maybe even AWT, assuming it is normal OS decorated window.

test on your OS please

Empire_Phoenix · July 7, 2014, 11:34am

Hm I just tested on my office pc at work, using a windows 7

-> The insets reported by getWindowDecoration size are correct (valdiated with screengrabber and pixel counting)

However it is still not correct there. (the original values work on windows tho)

I will test this evening under the linux at home, and see if it works there.

It might be that we need a os switch here, if the system works differently on windows.
eg use your solution for linux and a hardcoded for windows.

Anyway i found another context based problem with this.
I use a windowsfullscreen, eg add the following and set resolution to screenres.
System.setProperty(“org.lwjgl.opengl.Window.undecorated”,“true”);
Of course the jfx part does not know it can now safely skip the inset stuff.

This however is easily solvable, by adding
[java]
if (“true”.equalsIgnoreCase(System.getProperty(“org.lwjgl.opengl.Window.undecorated”))) {
return new Point(0, 0);
}
[/java]
At the start of the getWindowDecorationSize@JFXUtils
-> I think we should also move the fullscreenhandling there once this works, to have a cleaner data flow logic.

javasabr · July 9, 2014, 9:43am

@Empire Phoenix said: Hm I just tested on my office pc at work, using a windows 7
-> The insets reported by getWindowDecoration size are correct (valdiated with screengrabber and pixel counting)

However it is still not correct there. (the original values work on windows tho)

I will test this evening under the linux at home, and see if it works there.

It might be that we need a os switch here, if the system works differently on windows.
eg use your solution for linux and a hardcoded for windows.

Anyway i found another context based problem with this.
I use a windowsfullscreen, eg add the following and set resolution to screenres.
System.setProperty(“org.lwjgl.opengl.Window.undecorated”,“true”);
Of course the jfx part does not know it can now safely skip the inset stuff.

This however is easily solvable, by adding
[java]
if (“true”.equalsIgnoreCase(System.getProperty(“org.lwjgl.opengl.Window.undecorated”))) {
return new Point(0, 0);
}
[/java]
At the start of the getWindowDecorationSize@JFXUtils
-> I think we should also move the fullscreenhandling there once this works, to have a cleaner data flow logic.

test on your OS please

Empire_Phoenix · July 9, 2014, 11:03am

Hey thanks,

I will test on windows on friday,
tested so far on arch-linux and it still is offset, however i have the feeling that the window decorations are wrongly reported by my os in this case.
(so wait till i can test on windows)

javasabr · July 9, 2014, 12:31pm

@Empire Phoenix said: Hey thanks,
I will test on windows on friday,
tested so far on arch-linux and it still is offset, however i have the feeling that the window decorations are wrongly reported by my os in this case.
(so wait till i can test on windows)

please run test and

Empire_Phoenix · July 9, 2014, 1:37pm

Here is how it looks for me.

javasabr · July 10, 2014, 5:45am

@Empire Phoenix said: Here is how it looks for me.

It seems to me that it is impossible to make a universal approach, so it is going to have to use OS dependent indentation https://github.com/empirephoenix/JME3-JFX/pull/10 https://github.com/JavaSaBr/JME3-JFX/commit/a4cda3a8e03cbe63568a7772cb7646e4c9c2919c

Empire_Phoenix · July 11, 2014, 2:54pm

Hm yeah i think this will do the trick.

AT worst it wont break anything(mre than it currently is)
At best it’s possible to add offsets to it easily and hopefully in time get everything to work out of the box.

@abies any objects to merging this.

abies · July 11, 2014, 3:20pm

As I mentioned in one of previous pull requests, I don’t like whitespace changes mixed with code changes. Makes it very hard to spot if something else is not getting broken/changed by accident.

As for the actual approach - anything is better than hardcoded 3 and 25 ;), but I really doubt this approach will work. I’m quite sure that you can change windows manager/theme under linux and have same magic string reported by the tool (Ubuntu 14.04 LTS (trusty) is quite specific, won’t match 14.05, but will match 14.04 with KDE or gnome installed) but end up having different offset needed. Same probably will happen on windows when you use one of accessibility options which make window bars bigger.

What about just adding setter for offsets and letting people control it from outside for now?

Empire_Phoenix · July 11, 2014, 3:40pm

Hm i thought about adding a calibarte utility, that allows to add these live, so that in worst case the end user is capable of doing it via a console command or similar.

For linux I think querying the display manager might work quite good as os logic, and then asking it for further details.

Anyway i think forcing outside will remove the possibility for us to incorporate later a central solution once we found an good working way.

javasabr · July 12, 2014, 6:53am

What about just adding setter for offsets and letting people control it from outside for now?

In my game, I will also add to the indentation settings

javasabr · July 14, 2014, 7:59am

Why such a difference in drawing the transparent elements?

test 1

test 2