Re: How to make a large cursor in JavaFX 12

[info]

Hi Tom,

Thanks for your reply. The class ImageCursor does not responds to enlarging
my Image, which I hoped was the solution. My windows 10 platform itself
doesnot allow free sizing of the cursor. The maximum size offered (extreme
large) is still too small. I need at least 2-3 centimeters on the screen.

Best regards.


Op vr 21 jun. 2019 om 11:38 schreef Tom Schindl :

> Hi,
>
> Well this is something you can configure in your OS-Settings and FX will
> just pick it up. The only other option is to set a custom image.
>
> Tom
>
> On 21.06.19 09:52, Eef Custers wrote:
> > Hi,
> >
> > I am working on an application for visual impaired users. I like to
> create
> > a large cursor, but I cannot find a way how to do that. Can somebody push
> > me in the right direction?
> >
> > I am working with openjdk12 and javafx12 on windows10.
> > Thanks a lot,
> > regards.
> >
> > Eef
> >
>
> --
> Tom Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>

Re: Future of JavaFX

[info]

If it is not a part of OpenJDK/Oracle JDK it will not work. Whether  
Oracle itself maintains the code doesn't really matter I think, but  
they have to put support and development in it.


To me another downside if Oracle would suspend further development is  
that any statements made by Oracle seem to carry not so much value. If  
I'm correct JavaFX was presented by Oracle as the Swing replacement.  
If after a short time they revert from that position, what would that  
mean for any other statement?



Citeren Felix Bembrick :

If JavaFX stays under Oracle control, it will be the same it is  
today in 5 years. I really doubt they will put another dollar into  
its expansion and new features.


How can that be good?

Plus the company that does take over could provide commercial  
support as well as training (which Oracle doesn't).

OSGi bundle reloading and "Application launch must not be called more than once"

[info]

I'm using OSGi (Apache Felix) to develop my application. The bundle's  
activator is as follows:


@Override
public void start(BundleContext context) throws Exception {
		new Thread(() -> Application.launch(Desktop.class), "JavaFX Desktop  
launcher").start();

}

@Override
public void stop(BundleContext context) throws Exception {
Platform.exit();
}

The new Thread() is because Application.launch blocks the thread (can  
it be avoided?).


However, the main problem is when I stop a bundle, do an update and  
try to start it again. Unless I quit the entire OSGi container I get  
the following stacktrace:


g! Exception in thread "JavaFX Desktop launcher"  
java.lang.IllegalStateException: Application launch must not be called  
more than once
	at  
com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:162)
	at  
com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:143)

at javafx.application.Application.launch(Application.java:191)

While I understand this in a regular situation, it is kind of annoying  
in a environment such as OSGi. I would have thought that calling  
Platform.exit() in the activator's stop() method would have done the  
trick, but obviously it doesn't.


Is there a way to completely stop the JavaFX framework in the stop()  
method so that a subsequent call to start() will be capable of  
starting a new application?

Could not get native display: How is platformGetNativeDisplay() in AcceleratedScreen realized?

[info]

I'm runing my JavaFX application on a Udoo Quad, a ARMv7 with Vivante  
GPU. I haven't succeeded in using the GPU yet, and I'm endeavouring on  
the quest to find out why. It probably has to do something with  
drivers, missing libraries etc etc. I'm aware of the page "Porting  
JavaFX to additional embedded Linux devices" [1], although I haven't  
found the answer there yet that I need.


I tried to look inside the code to see how it works, and why the  
native display cannot be gotten. I found the code in  
AcceleratedScreen, but I fail to understand where a different  
resultcode of 0 is implemented, so who should realize the call? This  
will help me to look further.



The output of my javafx program is:

Prism pipeline init order: es2 sw
Using native-based Pisces rasterizer
Using dirty region optimizations
Using system sized 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_monocle
succeeded.
GLFactory using com.sun.prism.es2.MonocleGLFactory
com.sun.glass.ui.monocle.GLException: 0x0: Could not get native display
at  
com.sun.glass.ui.monocle.AcceleratedScreen.(AcceleratedScreen.j

ava:75)
at  
com.sun.glass.ui.monocle.MX6AcceleratedScreen.(MX6AcceleratedSc

reen.java:39)
at  
com.sun.glass.ui.monocle.MX6Platform.getAcceleratedScreen(MX6Platform

..java:39)
at  
com.sun.prism.es2.MonocleGLFactory.initialize(MonocleGLFactory.java:1

07)
at com.sun.prism.es2.ES2Pipeline.(ES2Pipeline.java:81)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:260)
at  
com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:1

87)
at  
com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(Quant

umRenderer.java:91)
at  
com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(Quantu

mRenderer.java:124)
at java.lang.Thread.run(Thread.java:745)
(X) Got class = class com.sun.prism.es2.ES2Pipeline
GraphicsPipeline.createPipeline: error initializing pipeline  
com.sun.prism.es2.E

S2Pipeline
*** Fallback to Prism SW pipeline
Prism pipeline name = com.sun.prism.sw.SWPipeline
(X) Got class = class com.sun.prism.sw.SWPipeline
Initialized prism pipeline: com.sun.prism.sw.SWPipeline
 vsync: true vpipe: false
Loading Prism common native library ...
succeeded.


Regards,
Maurice.

[1]  
https://wiki.openjdk.java.net/display/OpenJFX/Porting+JavaFX+to+additional+embedded+Linux+devices

Re: Could not get native display: How is platformGetNativeDisplay() in AcceleratedScreen realized?

[info]

Have found some further code in MX6AcceleratedScreen.c.

//Vivante specials
static EGLNativeDisplayType (*wr_fbGetDisplayByIndex)(int DisplayIndex);
static EGLNativeWindowType (*wr_fbCreateWindow)(EGLNativeDisplayType  
Display, int X, int Y, int Width, int Height);


JNIEXPORT jlong JNICALL  
Java_com_sun_glass_ui_monocle_MX6AcceleratedScreen__1platformGetNativeDisplay

(JNIEnv *env, jobject obj, jlong methodHandle) {
EGLNativeDisplayType cachedDisplay = NULL;

if (cachedDisplay == NULL) {
wr_fbGetDisplayByIndex = asPtr(methodHandle);
cachedDisplay = wr_fbGetDisplayByIndex(0);
}
return asJLong(cachedDisplay);
}

Now to find out why this fails. Maybe fbGetDisplayByIndex should use  
another value?


Maurice.

Re: [PATCH] buildscript java version detection fails on Linux/Ubuntu on Picked up JAVA_TOOL_OPTIONS

[info]

Citeren Kevin Rushforth kevin.rushfo...@oracle.com:
Either I can add your information to JDK-8133750 or you can file a  
new bug and I will link them together and fix them at the same time.

I'd prefer the former over the latter.

Maurice.

[PATCH] buildscript java version detection fails on Linux/Ubuntu on Picked up JAVA_TOOL_OPTIONS

[info]

I've adapted the build.gradle to use java -fullversion instead of java  
-version, parsing the result with a regexp.


diff -r 9b5fc7c1e5e6 build.gradle
--- a/build.gradle  Fri Aug 07 18:35:42 2015 -0700
+++ b/build.gradle  Thu Aug 27 15:52:11 2015 +0200
@@ -719,29 +719,27 @@
 if (!file(JAVAH).exists()) throw new Exception(Missing or incorrect  
path to 'javah': '$JAVAH'. Perhaps bad JDK_HOME? $JDK_HOME)
 if (!file(JAVADOC).exists()) throw new Exception(Missing or  
incorrect path to 'javadoc': '$JAVADOC'. Perhaps bad JDK_HOME?  
$JDK_HOME)


-
+
 // Determine the verion of Java in JDK_HOME. It looks like this:
 //
-// $ java -version
-// java version 1.7.0_45
-// Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
-// Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
-//
-// We need to parse the second line
-def inStream = new java.io.BufferedReader(new  
java.io.InputStreamReader(new java.lang.ProcessBuilder(JAVA,  
-version).start().getErrorStream()));

+// $ java -fullversion
+// for OpenJDK: openjdk full version 1.8.0_45-internal-b14
+// for Oracle JDK: java full version 1.8.0_45-b14
+
+def inStream = new java.io.BufferedReader(new  
java.io.InputStreamReader(new java.lang.ProcessBuilder(JAVA,  
-fullversion).start().getErrorStream()));

 try {
-if (inStream.readLine() != null) {
-String v = inStream.readLine();
-if (v != null) {
-int ib = v.indexOf( (build );
-if (ib != -1) {
-String ver = v.substring(ib + 8, v.size() - 1);
-
-defineProperty(jdkRuntimeVersion, ver)
-defineProperty(jdkVersion, jdkRuntimeVersion.split(-)[0])
-defineProperty(jdkBuildNumber,  
jdkRuntimeVersion.substring(jdkRuntimeVersion.lastIndexOf(-b) + 2))

-}
-}
+def v = inStream.readLine();
+
+if (v != null) {
+	def pattern =  
java.util.regex.Pattern.compile(^[^\]*\((\\d+(?:\\.\\d+)*)_(\\d+))(?:-\\w+)?(?:-b(\\d+))\\$)

+   def matcher = pattern.matcher(v)
+
+   if (matcher.matches()) {
+defineProperty(jdkVersion, matcher.group(1))
+defineProperty(jdkRuntimeVersion, matcher.group(2))
+defineProperty(jdkUpdate, matcher.group(3))
+defineProperty(jdkBuildNumber, matcher.group(4))
+   }
 }
 } finally {
 inStream.close();

Proposed fix: buildscript java version detection fails on Linux/Ubuntu on Picked up JAVA_TOOL_OPTIONS

[info]

The gradle build tries to find the version of the used Java JDK by 
running 'java -version', skipping the first line and expects to find the 
version in the second line.


However, on Linux (Ubuntu) the first line of *any* Java invocation is 
Picked up JAVA_TOOL_OPTIONS: 
-javaagent:/usr/share/java/jayatanaag.jar[1], thus failing at detection 
of the version, aborting the build.


The 'Pickup up...' line is a standard feature of the JDK and a legacy 
that doesn't seem to be removed soon[2].


I guess the build script needs to accommodate for this.

Proposed fix:

// Determine the verion of Java in JDK_HOME. It looks like this:
//
// $ java -version
// Picked up JAVA_TOOL_OPTIONS: 
-javaagent:/usr/share/java/jayatanaag.jar

// java version 1.7.0_45
// Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
// Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
//
// The first line is optional, we need to parse the third line
def inStream = new java.io.BufferedReader(new 
java.io.InputStreamReader(new java.lang.ProcessBuilder(JAVA, 
-version).start().getErrorStream()));

try {
String v = inStream.readLine();

if (v != null) {
if (v.startsWith(Picked up)) {
   inStream.readLine();
}

v = inStream.readLine();


[1] https://community.oracle.com/thread/1239778?start=0tstart=0
[2] https://bugs.openjdk.java.net/browse/JDK-8039152

Re: Proposed fix: buildscript java version detection fails on Linux/Ubuntu on Picked up JAVA_TOOL_OPTIONS

[info]

I was not aware of the existence of the -fullversion option. It is not 
listed at the Oracle site, afaik. Can it be assumed to be present in 
non-OpenJDK, non-Oracle JDKs?


David DeHaven schreef op 2015-08-26 15:38:
The gradle build tries to find the version of the used Java JDK by 
running 'java -version', skipping the first line and expects to find 
the version in the second line.


However, on Linux (Ubuntu) the first line of *any* Java invocation is 
Picked up JAVA_TOOL_OPTIONS: 
-javaagent:/usr/share/java/jayatanaag.jar[1], thus failing at 
detection of the version, aborting the build.


The 'Pickup up...' line is a standard feature of the JDK and a legacy 
that doesn't seem to be removed soon[2].


I guess the build script needs to accommodate for this.

Proposed fix:

// Determine the verion of Java in JDK_HOME. It looks like this:
//
// $ java -version
// Picked up JAVA_TOOL_OPTIONS: 
-javaagent:/usr/share/java/jayatanaag.jar

// java version 1.7.0_45
// Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
// Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
//
// The first line is optional, we need to parse the third line
def inStream = new java.io.BufferedReader(new 
java.io.InputStreamReader(new java.lang.ProcessBuilder(JAVA, 
-version).start().getErrorStream()));

try {
   String v = inStream.readLine();

   if (v != null) {
if (v.startsWith(Picked up)) {
   inStream.readLine();
}

   v = inStream.readLine();


Why not just use java -fullversion instead?

$ java -fullversion
java full version 1.8.0_60-ea-b14

$ JAVA_TOOL_OPTIONS=-Xmx512M java -fullversion
java full version 1.8.0_60-ea-b14

$ java -version
java version 1.8.0_60-ea
Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b14, mixed mode)

$ JAVA_TOOL_OPTIONS=-Xmx512M java -version
Picked up JAVA_TOOL_OPTIONS: -Xmx512M
java version 1.8.0_60-ea
Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b14, mixed mode)

It's a lot less stuff to parse. Also, java -fullversion does not
start the VM, so should be faster.

-DrD-

Touch Screen X-axis flipped on Udoo/3M Touchscreen EX_II

[info]

I have got the first incarnation of my JavaFX app running on my Udoo 
board, a FreeScale based ARM. It is using the sw pipeline, not the 
Vivante yet, but there is another problem first.


When I connect a mouse the mouse coordinates are interpreted correctly, 
but the touch events, or touch position is incorrect. When I run X11 
both mouse and touch is correct.


The Y axis follows the screen correctly, however the X axis seems to be 
flipped. I've run the app with flipXY, but that is incorrect as it flips 
both X  Y. I've also tried to set the minX and maxX the other way 
around, hoping that the LinuxTouchTransform would calculate the 
transform for X as -1, it doesn't unfortunately.


I don't know of another property to set. Is there any? If not, how can I 
contribute to the JavaFX project so that I can solve this?


Maurice.