Re: Planning for JavaFX.next

[Erik De Rijcke]

On of the major problems we have here using javafx is the the extremely
slow loading speed of the fxmls (we have about 15000+ arm cortex devices
running javafx in production). Sure, there is a lot to gain in manually
optimizing and reducing the number of nodes and whatnot, but that kinda
beats the purpose of having fast development cycle using jfx. As an
experiment we used a rather unkown/obscure fxml precompiler and noticed a
speed gain of 10s (worst case fxml) -> 0.1s!

My proposal is thus to absolutely have an fxml precompiler as the speed
gains are tremendous on slower devices.

Further I would +1 the CSS performance.

Another major hurdle we had was the complete inability to inter-operate
with any native hw acceleration (OpenGL ES2 to render a GPS navigator
inside the jfx app to be precise). Sure I understand the need to abstract
things away given that the user/programmer should not notice what platform
he's running on. In reality it is often very well known which platform will
be used. It would be nice to at least have some handles (through JNI?) to
use the existng jfx rendering context and issue your own custom gl
commands. Now we ended up rendering in a separate context and doing a
glreadpixels, copy that to the java/jfx side and render to an image.
Needless to say the performance is shi^H^H^H not good.

In general would say to have a look at your main competitor (Qt-gui imho),
see what jfx does well and make sure it keeps doing that, and see what
Qt-gui does better (speed, qml, native api exposure, wayland support to
name a few)  and improve upon that.

2016-12-08 10:22 GMT+01:00 Dirk Lemmermann :

> I have these priorities regarding the items mentioned by Jonathan:
>
> “Put the pedal to the metal” section:
>   +1 CSS performance improvements
>   +1 TableView performance
>   +1 Marlin renderer enabled by default
>
> “The rest” section:
>   +1 TableView improvements (cell spanning, row / column freezing, etc)
>   +1 Focus traversal API
>   +1 A JavaFX equivalent of the AWT Desktop APIs
>
> —Dirk
>
> http://www.dlsc.com

Re: Issues porting to Monocle EPD platform

[Erik De Rijcke]

Hi John,

In regard to your input issue. If it's a possibility, I'd recommend looking
at 'libinput'. It's an generic input abstraction library. It might be more
up to date and provide quirk fixes for (all kind of) input hardware.
https://wayland.freedesktop.org/libinput/doc/latest/
It's already the default input library used by X.org and Wayland
compositors but is in no way dependend on them.

regards,

Erik


On Mon, Nov 7, 2016 at 7:07 PM, David Hill  wrote:

> On 11/7/16, 12:55 PM, John Neffenger wrote:
>
> Hi John,
> I am probably the guy that will be looking over these, but I am in the
> middle of a big push. Feel free to ping me offline if I don't get back to
> you by early next week.
>
> Dave
>
> While porting OpenJFX to devices with an electronic paper display, I
>> resolved three issues in the graphics module that I thought I should pass
>> along. The following merge request on GitLab lists the issues and my minor
>> changes. See the Commits and Changes tabs in the middle of the page for
>> details.
>>
>> WIP: Patches to OpenJFX
>> https://gitlab.com/openjfxepd/jfxpatch/merge_requests/1
>>
>> Did I understand the code correctly? I would appreciate any feedback.
>>
>> As a brief summary, the first issue, "QuantumRenderer modifies buffer in
>> use by JavaFX Application Thread," may be of general interest because it
>> occurs on the Monocle Headless and VNC platforms.
>>
>> The second issue, "zForce touchscreen input device fails when closed and
>> immediately reopened," might affect only my platform, or maybe just the
>> older Linux kernel and device driver I'm forced to use, but I couldn't find
>> a good workaround without duplicating the entire LinuxInputDevice class.
>>
>> The third issue, "Get two bytes for the Linux input event type, not
>> four," doesn't seem to cause any problems, but may still be worth fixing.
>>
>> Thank you,
>> John
>>
>
>
> --
> David Hill
> Java Embedded Development
>
> "A man's feet should be planted in his country, but his eyes should survey
> the world."
> -- George Santayana (1863 - 1952)
>
>

Re: [9] Review request for 8157213: HiDPI support for Linux creates unnecessary dependency

[Erik De Rijcke]

Yes that seems to fix it.

On Wed, May 18, 2016 at 9:55 PM, Jim Graham <james.gra...@oracle.com> wrote:

> Ah, this is probably me returning a -1 as an uint.  If you change the
> "defval" used (line 167) in the call to query the property from -1 to 0
> does it work as intended?
>
> ...jim
>
>
> On 5/18/16 11:59 AM, Erik De Rijcke wrote:
>
>> I tested the patch.
>>
>> Without the dependency I get a an enormous stage (I explicitly set it to
>> be 100x100). Debugging shows me the screen is
>> initialized with these values:
>>
>> Screen:
>> ptr:0
>> adapter:0
>> depth:24
>> x:0
>> y:0
>> width:0
>> height:0
>> platformX:0
>> platformY:0
>> platformWidth:1680
>> platformHeight:946
>> visibleX:0
>> visibleY:0
>> visibleWidth:0
>> visibleHeight:0
>> platformScaleX:4.2949673E9
>> platformScaleY:4.2949673E9
>> outputScaleX:4.2949673E9
>> outputScaleY:4.2949673E9
>> resolutionX:0
>> resolutionY:0
>>
>>
>> I assume the scaling factor is not what it should be?
>>
>> With the dependency installed the stage looks fine.
>>
>> On Wed, May 18, 2016 at 5:52 AM, Jim Graham <james.gra...@oracle.com
>> <mailto:james.gra...@oracle.com>> wrote:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8157213
>> webrev: http://cr.openjdk.java.net/~flar/JDK-8157213/webrev-00/
>>
>> Details of what was fixed are listed in the bug report.  This will
>> hopefully fix all of the dependencies that Erik
>> ran into in his Gentoo environment...
>>
>> ...jim
>>
>>
>>

Re: Support for GTK 2 & 3 now in JFX

[Erik De Rijcke]

Hi,

I tried using the gtk3 broadway backend. This results in a segfault.

Current thread (0x7fe8cc0c2000):  JavaThread "GtkNativeMainLoopThread"
[_thread_in_native, id=21171, stack(0x7fe8abcad000,0x7fe8abdae000)]

Stack: [0x7fe8abcad000,0x7fe8abdae000],  sp=0x7fe8abdac1c0,
 free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
code)
C  [libX11.so.6+0x2d32a]  XInternAtom+0x2a

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j
 
com.sun.glass.ui.gtk.GtkApplication.staticScreen_getScreens()[Lcom/sun/glass/ui/Screen;+0
j  com.sun.glass.ui.Screen.initScreens()V+6
j  com.sun.glass.ui.Application.lambda$run$1(Ljava/lang/Runnable;)V+0
j  com.sun.glass.ui.Application$$Lambda$44.run()V+4
v  ~StubRoutines::call_stub
j  com.sun.glass.ui.gtk.GtkApplication._runLoop(Ljava/lang/Runnable;Z)V+0
j
 com.sun.glass.ui.gtk.GtkApplication.lambda$runLoop$8(Ljava/lang/Runnable;Z)V+7
j  com.sun.glass.ui.gtk.GtkApplication$$Lambda$48.run()V+12
j  java.lang.Thread.run()V+11
v  ~StubRoutines::call_stub

It looks like there are still some hard dependencies on X which will
obviously not work using a non X gtk back-end. (I verified the broadway
backend works by running the gtk3-demo app in my browser first).

On Wed, May 18, 2016 at 3:06 AM, Jim Graham <james.gra...@oracle.com> wrote:

> Hi Erik,
>
> I tried testing our build under a Gentoo LiveCD.  Even the minimal
> environment of the LiveCD has the org.gnome.desktop.interface schema
> defined so I'm not sure how minimal your environment was.  I did discover
> that, although the schema was there, it had a value of "0" for the
> scaling-factor which caused us to create bogus logical screen sizes that
> probably caused the exception you saw, so simply finding that schema and
> key is not enough for us to trust the value.  I'll add some protection for
> bad data from the key, but I'm curious to find out how minimal your install
> was and whether we should simply state our dependency, or if your
> configuration is likely to be common enough that we should protect against
> it in our code...?
>
> Also, what does:
>
> % gsettings get org.gnome.desktop.interface scaling-factor
>
> return for your system?  If you set it to "1", does FX come up fine?
>
> ...jim
>
>
> On 05/16/2016 01:01 PM, Jim Graham wrote:
>
>> These may both be related to the HiDPI fix instead.  I added a usage of
>> g_settings in that fix that went in on Friday.  It looks like I'll have
>> to check for the schema existing before I access it.
>>
>> Can you file a bug report?
>>
>> (On a side note, the call that grabs the schema does not have a "schema
>> not known" return value - if you ask for a schema that doesn't exist
>> they abort your application.  Seems kind of drastic, but the bug reports
>> that request that they simply return null were met with push back
>> because the developers couldn't imagine why anyone would want such a
>> thing (huh?) and later an attempt to return NULL on unrecognized schemas
>> and keys had to be backed out because of the huge disaster the NULL
>> values caused (and somehow ABORT'ing on behalf of the application is
>> better in that case?).  Unfortunately I don't see much sanity in those
>> APIs or any support for a case like this of "I'd like to get that value,
>> but if you haven't heard of it, that's fine as I have a backup plan".
>> The only way around this will be to enumerate all schemas and all keys
>> and see if the ones we want are found in the list - a rather extreme
>> workaround for bad error handling behavior in their APIs...)
>>
>>  ...jim
>>
>> On 05/16/2016 05:15 AM, Erik De Rijcke wrote:
>>
>>> I ran into several issues, however I'm not sure they are related to gtk3
>>>
>>> first of all it seems there is a dependency on:
>>> gsettings-desktop-schemas.
>>> I'm not sure how desirable this is (I did not have it installed,
>>> installing
>>> it fixed the error but I can image people not wanting to install it?)
>>>
>>> Second, and this seems unrelated to gtk(3?), the screen initialization
>>> fails (test was done using gentoo linux on virtualbox with windows 7 as
>>> host):
>>>
>>> Exception in thread "JavaFX Application Thread"
>>> java.lang.IllegalArgumentException: Both width and height must be >= 0
>>>
>>> at javafx.geometry.Rectangle2D.(Rectangle2D.java:104)
>>> at javafx.stage.Screen.nativeToScreen(Screen.java:152)
>>> at javafx.stage.Screen.updateConfiguration(Screen.java:88)
>>> at javaf

Re: [9] Review request for 8157213: HiDPI support for Linux creates unnecessary dependency

[Erik De Rijcke]

I tested the patch.

Without the dependency I get a an enormous stage (I explicitly set it to be
100x100). Debugging shows me the screen is initialized with these values:

Screen:
ptr:0
adapter:0
depth:24
x:0
y:0
width:0
height:0
platformX:0
platformY:0
platformWidth:1680
platformHeight:946
visibleX:0
visibleY:0
visibleWidth:0
visibleHeight:0
platformScaleX:4.2949673E9
platformScaleY:4.2949673E9
outputScaleX:4.2949673E9
outputScaleY:4.2949673E9
resolutionX:0
resolutionY:0


I assume the scaling factor is not what it should be?

With the dependency installed the stage looks fine.

On Wed, May 18, 2016 at 5:52 AM, Jim Graham  wrote:

> bug: https://bugs.openjdk.java.net/browse/JDK-8157213
> webrev: http://cr.openjdk.java.net/~flar/JDK-8157213/webrev-00/
>
> Details of what was fixed are listed in the bug report.  This will
> hopefully fix all of the dependencies that Erik ran into in his Gentoo
> environment...
>
> ...jim
>
>

Re: Support for GTK 2 & 3 now in JFX

[Erik De Rijcke]

I ran into several issues, however I'm not sure they are related to gtk3

first of all it seems there is a dependency on: gsettings-desktop-schemas.
I'm not sure how desirable this is (I did not have it installed, installing
it fixed the error but I can image people not wanting to install it?)

Second, and this seems unrelated to gtk(3?), the screen initialization
fails (test was done using gentoo linux on virtualbox with windows 7 as
host):

Exception in thread "JavaFX Application Thread"
java.lang.IllegalArgumentException: Both width and height must be >= 0

at javafx.geometry.Rectangle2D.(Rectangle2D.java:104)
at javafx.stage.Screen.nativeToScreen(Screen.java:152)
at javafx.stage.Screen.updateConfiguration(Screen.java:88)
at javafx.stage.Screen.checkDirty(Screen.java:82)
at javafx.stage.Screen.getPrimary(Screen.java:185)
at
com.sun.javafx.tk.quantum.QuantumToolkit.initSceneGraph(QuantumToolkit.java:298)
at
com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(QuantumToolkit.java:340)
at
com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(QuantumToolkit.java:257)
at com.sun.glass.ui.Application.lambda$run$1(Application.java:155)
at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method)
at
com.sun.glass.ui.gtk.GtkApplication.lambda$runLoop$7(GtkApplication.java:194)
at java.lang.Thread.run(Thread.java:804)


Nearly all values seem to be -2147483648


I used openjdk9 109 as per instructions of the wiki, and the latest javafx
dev.


On Mon, May 9, 2016 at 8:56 PM, Jim Graham  wrote:

> Should we integrate that into prism.verbose output?
>
> ...jim
>
>
> On 5/9/16 6:18 AM, David Hill wrote:
>
>>
>> I added a new feature Friday and would like some help testing it.
>>
>> This new feature (8087516: Conditional support for GTK 3 on Linux) allows
>> us to use either GTK v2 or 3 with JavaFX.
>>
>> The default has not changed - we will use gtk 2 by preference.
>>
>> The help I need is for anyone doing testing on Linux with the current
>> tree - like todays sanity testing. Adding
>>
>> -Djdk.gtk.verbose=true
>>
>> should output the version detected and used. I would appreciate a paste
>> of that along with the OS version.
>>
>> -Djdk.gtk.version=3
>>
>> toggles the preferred version to GTK 3. Testing using that toggled would
>> also be appreciated, along with a note to me
>> with the OS version.
>>
>> thanks!
>>
>>

Re: Support for GTK 2 & 3 now in JFX

[Erik De Rijcke]

Hi,

Are there any known limitations on the gtk3 backends (html5, wayland, ...)
that could be used?

regards,

Erik

On Mon, May 9, 2016 at 3:18 PM, David Hill  wrote:

>
> I added a new feature Friday and would like some help testing it.
>
> This new feature (8087516: Conditional support for GTK 3 on Linux) allows
> us to use either GTK v2 or 3 with JavaFX.
>
> The default has not changed - we will use gtk 2 by preference.
>
> The help I need is for anyone doing testing on Linux with the current tree
> - like todays sanity testing. Adding
>
> -Djdk.gtk.verbose=true
>
> should output the version detected and used. I would appreciate a paste of
> that along with the OS version.
>
> -Djdk.gtk.version=3
>
> toggles the preferred version to GTK 3. Testing using that toggled would
> also be appreciated, along with a note to me with the OS version.
>
> thanks!
>
> --
> David Hill
> Java Embedded Development
>
> "A man's feet should be planted in his country, but his eyes should survey
> the world."
> -- George Santayana (1863 - 1952)
>
>

Re: What does this mean for the future of JavaFX on iOS?

[Erik De Rijcke]

I'm currently looking if I can get some robovm fork kickstarted. (
https://github.com/FlexoVM/flexovm/issues/4 ).

It's really a shame that for this one time Java has a real nice aot
llvm compiler, MS kills it. Being able to compile Java (or any
bytecode language) to a native, fast and small executable (especially
for arm/embedded use which does not require an Oracle license) would
be *really* cool. Let's see if we can continue to make this happen in
one way or another.

On Mon, Apr 18, 2016 at 7:20 PM, Felix Bembrick
 wrote:
> So what AOT will you be using now? The last RoboVM AOT or something else?
>
>> On 19 Apr 2016, at 03:15, Johan Vos  wrote:
>>
>> Indeed, this doesn't have any impact on JavaFX.
>> The Gluon tools are currently using the RoboVM AOT 1.8, which was the last 
>> open-source version.
>>
>> RoboVM delivered a whole set of products, including an AOT, but also a 
>> system that provides some JNI functionality, a set of bindings that create 
>> Java classes that have a 1-1 mapping to native iOS classes, and a whole 
>> "Studio" allowing developers to create applications.
>>
>> Only the AOT is relevant to us. We don't use the bindings, as we happen to 
>> have a great set of UI classes: the JavaFX platform. We don't need the 
>> studio, as we directly provide plugins for NetBeans, IntelliJ and Eclipse.
>>
>> The idea of JavaFX is to deliver a cross-platform UI for all devices. RoboVM 
>> took a different approach, as they mainly promoted creating an iOS specific 
>> UI (using the Java bindings to the native iOS UI components) and an Android 
>> specific UI.
>>
>> We had different views on a cross-platform UI (JavaFX) versus a 
>> platform-specific UI, but here is no doubt the RoboVM team consist of great 
>> developers and it is a real pity and shame they won't be able to continue 
>> working on their product.
>>
>> But for JavaFX and Gluon, it doesn't make a difference.
>>
>> - Johan
>>
>>
>>> On Mon, Apr 18, 2016 at 6:52 PM, Steve Hannah  wrote:
>>> According to Gluon, they're not impacted by this.
>>> https://twitter.com/GluonHQ/status/721784161728471041
>>>
>>>
>>>
 On Mon, Apr 18, 2016 at 9:36 AM, Felix Bembrick  
 wrote:
 I just read this article which states that RoboVM is effectively "shutting 
 down".

 https://www.voxxed.com/blog/2016/04/robovm/

 Given that they seem to be a critical part of the puzzle that is making 
 JavaFX viable on mobile platforms, what does this actually mean for that 
 goal?

 Is there an alternative technology or product that can fill this void? Or 
 is the final nail in the coffin for JavaFX to ever be a truly viable cross 
 platform technology?

 Thanks,

 Felix
>>>
>>>
>>>
>>> --
>>> Steve Hannah
>>> Web Lite Solutions Corp.
>>

Re: GLS language errors (Was: Internal error: Error loading stock shader FillRoundRect_LinearGradient,_PAD on Vivante ARM)

[Erik De Rijcke]

I'm not a shader expert  either but I have worked (and written some myself)
with them, so I'll give my 0.02$ (given that I have no idea what the
complete shader looks like)

It looks to me like the initialization of a default scoped global (eg
Johan's vec2 pixcoord) is done using non constant variables. What that
means is if those variables are  'varying' variables or basically anything
that is only know at the time the shader is invoked... well that's a
paddlin' because you are referring to per invocation scoped variables (like
'gl_FragCoord' but anything with a 'varying' or maybe
even 'uniforms'storage qualifier might fail too I would assume?) to
one-time initialize a global.

Mostly guessing on my part but defining a default scoped global that you
only need in your main is considered very naughty anyway (even if it works).

On Tue, Mar 1, 2016 at 2:23 PM, Maurice  wrote:

> I'm not very familiar with shader coding, but can't this be solved by
> putting a non-constant modifier in fron of it? I notice other variables are
> declared as 'varying' or 'uniform'.
>
> Maurice.
>
> Op 29-02-16 om 20:45 schreef Johan Vos:
>
>> Hi,
>>
>> It seems to me you might be running in the same issue we had on Android
>> with the recent Adreno drivers:
>> http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-July/017575.html
>>
>> See that thread for discussion, and for a fix-proposal here:
>> https://bitbucket.org/javafxports/8u60-rt/commits/595633bbaae36f98d85d47d276294442ea43488c
>>
>> Reading back that thread, I still have a todo on trying to find a generic
>> solution for this...
>>
>> - Johan
>>
>> On Sun, Feb 28, 2016 at 6:33 PM, Maurice  i...@cuhka.com>> wrote:
>>
>>   When I run the glslangValidator on
>> FillRoundRect_LinearGradient_PAD.frag it gives the following error:
>> ERROR: 0:19: 'non-constant global initializer' : not supported
>> with this profile: es
>>
>> When I move pixcoord's declaration on line 19 into the main()
>> function it gives no errors.
>>
>> This is the full output of find -name "*.frag" -exec
>> glslangValidator {} \;
>>
>> ERROR: 0:53: 'oTexCoords' : undeclared identifier
>> ERROR: 0:53: 'texture2D' : no matching overloaded function found
>> ERROR: 0:53: '=' :  cannot convert from 'const float' to 'temp
>> highp 4-component vector of float'
>> ERROR: 3 compilation errors.  No code generated.
>>
>>
>> ERROR: 0:55: 'oTexCoords' : undeclared identifier
>> ERROR: 0:55: 'texture2D' : no matching overloaded function found
>> ERROR: 0:55: 'scalar swizzle' : not supported with this profile: es
>> ERROR: 0:55: 'rgb' : vector field selection out of range
>> ERROR: 0:55: '=' :  cannot convert from 'const float' to 'temp
>> highp 3-component vector of float'
>> ERROR: 5 compilation errors.  No code generated.
>>
>>
>> ERROR: 0:53: 'oTexCoords' : undeclared identifier
>> ERROR: 0:53: 'texture2D' : no matching overloaded function found
>> WARNING: 0:53: 'return' : type conversion on return values was not
>> explicitly allowed until version 420
>> ERROR: 2 compilation errors.  No code generated.
>>
>>
>> ERROR: 0:55: 'oTexCoords' : undeclared identifier
>> ERROR: 0:55: 'texture2D' : no matching overloaded function found
>> ERROR: 0:55: 'scalar swizzle' : not supported with this profile: es
>> ERROR: 0:55: 'rgb' : vector field selection out of range
>> ERROR: 0:55: '=' :  cannot convert from 'const float' to 'temp
>> highp 3-component vector of float'
>> ERROR: 5 compilation errors.  No code generated.
>>
>>
>> ERROR: 0:18: 'non-constant global initializer' : not supported
>> with this profile: es
>> ERROR: 1 compilation errors.  No code generated.
>>
>>
>> ERROR: 0:18: 'non-constant global initializer' : not supported
>> with this profile: es
>> ERROR: 1 compilation errors.  No code generated.
>>
>>
>> ERROR: 0:53: 'oTexCoords' : undeclared identifier
>> ERROR: 0:53: 'texture2D' : no matching overloaded function found
>> ERROR: 0:53: '=' :  cannot convert from 'const float' to 'temp
>> highp 4-component vector of float'
>> ERROR: 3 compilation errors.  No code generated.
>>
>>
>> ERROR: 0:55: 'oTexCoords' : undeclared identifier
>> ERROR: 0:55: 'texture2D' : no matching overloaded function found
>> ERROR: 0:55: 'scalar swizzle' : not supported with this profile: es
>> ERROR: 0:55: 'rgb' : vector field selection out of range
>> ERROR: 0:55: '=' :  cannot convert from 'const float' to 'temp
>> highp 3-component vector of float'
>> ERROR: 5 compilation errors.  No code generated.
>>
>>
>> ERROR: 0:53: 'oTexCoords' : undeclared identifier
>> ERROR: 0:53: 'texture2D' : no matching overloaded function found
>> WARNING: 0:53: 'return' : type conversion on return values was not
>> explicitly allowed until version 420
>> ERROR: 2 compilation errors.  No code 

Re: JFX as an OSGi service?

[Erik De Rijcke]

This way only the app will be accessible by other components through the
service registry. The app itself can not have any @reference because it it
is javafx itself that instantiates the app object and not the osgi
declarative services framework (which also takes care of injecting your
dependencies).

The way to work around this in java8 is to take the approach I describe, as
far as I know that is the only workaround to get scr and javafx glued
together.

In javafx 9 this would be fixed by having your service component implement
runnable and use the api described by kevin, as you can reuse the object
created by the osgi framework.

On Sat, Feb 20, 2016 at 3:27 PM, Maurice  wrote:

> That is why the bundle activator creates a bundle-singleton of itself,
> that way the app can access the OSGi world. In my case to register itself
> as a service.
>
>
> @Override
> public void start(Stage primaryStage) throws Exception {
> 
> primaryStage.show();
>
> Dictionary properties = createDictionary();
> BundleContext bundleContext =
> UdooActivator.bundleActivator().getBundleContext();
> bundleContext.registerService(com.cuhka.home.application.Application.class,
> this, properties);
> }
>
> Maurice.
> Op 20-02-16 om 15:08 schreef Stephen Winnall:
>
> Hi Maurice
>>
>> I have done something similar, but it has the following drawback in my
>> view: the class launched (Udoo15App in your case) does not run under OSGi
>> control, so it has no access to OSGi bundles or services, nor is it
>> accessible by them. If you don’t need that, you're OK. But I need that
>> class to be part of the OSGi world because other bundles/services are going
>> to add parts to the UI as they are instantiated.
>>
>> Steve
>>
>> On 20 Feb 2016, at 14:33, Maurice  wrote:
>>>
>>>
>>> For my OSGi based JavaFX solution on the Udoo Quad (ARM based Linux) I
>>> created a service that publishes the application in the context.The
>>> application does as little as possible. It sets up the primary stage as
>>> fullscreen and puts a stackpane in it. Initially the stackpane displays a
>>> 'boot logo', until the actual desktop bundle is started and registered with
>>> the application. Note that you have to start the application on a separate
>>> thread, as the thread will be blocked.
>>>
>>> On Java 8 this means that although the application bundle can't be
>>> updated in a running OSGi container, but that is why the desktop exists. On
>>> startup it registers itself, and thus the application content, with the
>>> application, and when it is stopped it removes the content from the
>>> application. The application has thus rarely to be updated itself.
>>>
>>> Regards,
>>> Maurice.
>>>
>>>
>>>
>>> public class UdooActivator implements BundleActivator {
>>> private static UdooActivator activator;
>>> private BundleContext context;
>>>
>>> static UdooActivator bundleActivator() {
>>> return requireNonNull(activator, "activator not set");
>>> }
>>>
>>> @Override
>>> public void start(BundleContext context) throws Exception {
>>> this.context = context;
>>> activator = this;
>>> new Thread(() -> Application.launch(Udoo15App.class), "JavaFX
>>> Desktop launcher").start();
>>> }
>>>
>>> @Override
>>> public void stop(BundleContext context) throws Exception {
>>> Platform.exit();
>>> }
>>>
>>> public BundleContext getBundleContext() {
>>> return context;
>>> }
>>> }
>>>
>>> Op 20-02-16 om 01:28 schreef Stephen Winnall:
>>>
 Anirvan, Kevin

 Thanks for this.

 I’m an expert neither in JavaFX nor in OSGi, but I think the basis of
 the JavaFX/OSGi incompatibility is control. To work with OSGi, JavaFX has
 to relinquish control of its startup sequence to OSGi in such a way that
 javafx.application.Application (or its proxy) is instantiated by OSGi and
 submits to OSGi’s bundle/service lifecycle. AN OSGi expert can probably
 formulate this better…

 Platform.startup(runnable) /might/ do it. Platform.launch(class)
 doesn’t because the object thereby instantiated is always under the control
 of JavaFX - and thus not of OSGi.

 I’m not comfortable using JFXPanel: if I wanted to use Swing I wouldn’t
 be trying to use JavaFX. But thank you for the hint.

 Steve

 On 19 Feb 2016, at 16:41, Kevin Rushforth
> wrote:
>
> And for JDK 9 there is now:
>
>  Platform.startup(Runnable);
>
> -- Kevin
>
>
> Anirvan Sarkar wrote:
>
>> Hi Stephen,
>>
>> FYI, there is another way of initializing JavaFX runtime. Just use:
>>
>> new JFXPanel();
>>
>> It is documented[1] that FX runtime is initialized when the first
>> JFXPanel
>> instance is constructed.
>>
>> Also JavaFX 9 will provide an official API to start 

Re: JFX as an OSGi service?

[Erik De Rijcke]

Hi Stephen,

We use JavaFX in an OSGi container, as a service component, in production,
so it's perfectly possible.

However there are a few gotcha's you need to take into account (I can not
c/p the code for obvious reasons...) which makes using it in osgi... quite
horrible :)

When triggering a javafx application in say, your component activate method
(as we do), you're actually creating a new javafx application instance, a
whole new identical object but without any scr dependency injection.

This is problematic as your osgi object has all the dependencies injected
from the osgi container while the javafx object does not.

What we do is this: in our activate we copy all our osgi dependencies, as
well as our ourself (this) to static fields, this makes them accessible in
the start method of the javafx object. When start is called, we store the
javafx object in a static field (which we access by calling 'this' in the
start method). We now have access to all dependencies and both objects at
any time. Now it's just matter of delegating calls from one instance to
another if needed...

btw, don't forget to call launch in a separate thread in your activate,
else you'll block your bundle activator thread indefinitely oh *and* sync
(block) your osgi component activate until the start method of your javafx
has finished else your component will announce itself activated while
javafx is still busy initializing.

Oh another gotcha, try to avoid using Platform.runLater, as that will only
work *after* your application component was activated, instead make a non
static runLater method in your osgi javafx application component and use
that. That will ensure that javafx was initialized before invoking any
platform run later.

Unfortunately javafx has a lot of static { Platform.RunLater} calls spread
out in different classes, so don't try to load those classes before your
javafx application was started... OUCH!

Didn't I say it was hairy and messy? JavaFX and OSGi is quite a bad match
unfortunately.

On Thu, Feb 18, 2016 at 3:38 PM, Stephen Winnall  wrote:

> I am trying to make JavaFX 8 work with OSGi Declarative Services. My
> preferred solution would be to instantiate javafx.application.Application
> as an OSGi service.
>
> As I understand it, there are two ways of activating JavaFX:
>
> 1) sub-class javafx.application.Application or
> 2) call javafx.application.Application.launch()
>
> However, both of these approaches give me a POJO, which makes interaction
> with OSGi services and bundles very difficult.
>
> Is there a “proper” way of starting JavaFX as an OSGi service? If not, are
> there any plans to support this?
>
> Regards,
> Steve

Re: performance on iOS

[Erik De Rijcke]

Disclaimer: I have not looked at the demo you're trying to run. I'm no
opengl expert so my advice might be a bit off, but I do know the basics of
gl programming.

I'm not familiar with JavaFX opengl rendering algorithm but is it really
needed to create a new (sub)texture object so many times? You're basically
asking the GPU to allocate a new piece of vmemory every time *and*
uploading your data to it *and* destroying it afterwards when no longer
needed... It might be better to either cache your textures and upload your
data to it async (lots of methods to do that online) or have some kind of
texture atlas or most likely: revise the way the jfx rendering algorithm
works. Also, you're profiling CPU time of the glTexSubImage2D function,
which might stall (sync call possibly) on iOS if the gpu is busy.



On Wed, Apr 8, 2015 at 9:12 AM, Johan Vos jo...@lodgon.com wrote:

 Hi,

 I did some performance tests on Android and iOS. I am using
 https://github.com/Ciruman/DemoFX.git which is forked from
 https://github.com/chriswhocodes/DemoFX and made mobile-ready.

 On my Nexus 5, I easily get 30 fps with triangles (the first test). On my
 old iPad, this is only 3 fps. I've reports we achieve 5-6 fps on an iPad
 Air.

 Digging into the potential bottlenecks, I found out that the native
 function responsible for 50% of the CPU time is glTexSubImage2D which seems
 to be slow on iOS (e.g. see
 http://stackoverflow.com/questions/21162688/gltexsubimage2d-slow-on-ios7)
 but it is heavily used in prism-es2.

 Any advice?

 Thanks,

 - Johan

Re: libjfxmedia.so on armv6hf?

[Erik De Rijcke]

Why didn't you target drm/kms gl  approach? I realise not all platforms
support this, but it would greatly extend the number of supported
(embedded) platforms in a generic way. A quick google search seems to
indicate that the sgx530 (BBB) has a kms driver as does the vivante (imx6).
An RPi drm/kms driver also seems to be in the works and a lot of upcoming
arm gpu's seem to be supported as well. By targeting kms/drm you'd be
supporting a lot of platforms with a single codepath now and in the future.

Unrelated, embedded jfx should use
http://wayland.freedesktop.org/libinput/doc/latest/ instead of it's own
bug-risky evdev/raw kernel input implementation. ;)

Now if just somebody would sponser me so I can work fulltime to implement
these things ;)

On Tue, Mar 17, 2015 at 7:39 PM, David Hill david.h...@oracle.com wrote:

 On 3/17/15, 8:04 AM, Erik De Rijcke wrote:

 Why are there limitations on the embedded port of javafx to begin with?
 Are there technical reasons for it?

 Quite a few actually

 The embedded platforms have quite a few features that make them
 difficult. (and I have the bruises to prove it :-)

 To start with, an embedded application is usually a single purpose
 instead of a general purpose computing device. Think a kiosk for example.
 When I say general purpose devices - I mean classic desktops and now the
 mobile platforms, where the expectation is that the machine will be used
 for a number of application.

 Several of you will say that I am wrong, that a Raspberry Pi for example
 behaves just like a pokey desktop machine. This is a case where the lines
 have blurred and will continue to get more blurry. The Pi was one of a new
 generation of ARM platforms that have a community around them - a place
 where you can both buy a cheap board and get an OS and drivers without an
 NDA. So just as you can make a kiosk using a desktop machine, you can also
 use the PI with XMBC as a media center.

 As part of the embedded FX team, our design center was less the Pi
 running with X11, but rather a direct to framebuffer (without the overhead
 and limitations of X11). And the Pi was an after thought for us, a way to
 help out the community. We were targeting a more modern platforms liek the
 i.MX6.

 The problem with the direct to framebuffer, and to some extent with the
 rest of the ARM platforms - the platforms are really fractured and it is
 hard to build a working distro. I personally spend many a frustrating day
 trying to get some ARM platform to do something we take for granted on the
 desktop. Starting with OpenGLES drivers, especially ones that would
 talk to the framebuffer (and not X11). The Pi is one of the few examples
 out there of a port that has an easy download that contains most of the
 needed drivers already integrated (and documented). I spent almost a week
 fighting the Beagle Bone Black before getting up. Oh yes - and add on top
 of this all that GL initialization direct to framebuffer is non-standard
 API, so we ended up with 3 code paths for the platforms we were able to
 build.

 So in summary it is easy to download a Linux distro. The hardpart is right
 after you do that, and you want the proprietary hardware accelerated
 drivers. There are very few platforms that make this easy.

 And the Pi (version 1) is really too slow. The i.MX6 has enough power for
 a real application. The ODROID U3 and XU are also pretty spiffy, but I
 could not get direct to framebuffer working for either of those. If you
 want to use X11 - OpenJFX will probably work for you, and it might even
 have graphical acceleration if the drivers are present and integrated.

 Our Embedded team had ARM media as the next big thing to do, but ...

 So now we have all of the gstreamer code in the OpenJFX repo. I really
 expect that media on the Pi (1) will probably not work well due to the
 speed of the CPU and the memory bus. Maybe the Pi 2.

 Again, you really need the right drivers in place to take advantage of
 hardware accelerated decoding of the media stream.

 With the right gstreamer libraries and drivers, I expect the media port
 would not take that long for someone that understands gstreamer.

 There might need to be some changes in Monocle to take the video stream
 hand off.

 I really would not expect that media would work without some debugging,
 and that after getting the build issues worked out.




 If you think about it, It's arm, so it's embedded. It's x86 so it's
 desktop doesn't make much sense... (atom is embedded, and there are arm
 windows netbooks that are not).

 Anyway, as a workaround, can't openjfx simply be compiled on an arm host
 (so no cross compilation is required) and as such generate the missing
 libraries? Qemu with an arm vm can be used to do that on an x86 host for
 example.

 On Tue, Mar 17, 2015 at 12:50 PM, Fabrizio Giudici
 fabrizio.giud...@tidalwave.it  wrote:

  On Tue, 17 Mar 2015 01:21:29 +0100, Felix Bembrick
 felix.bembr...@gmail.com  wrote:

   I really

Re: libjfxmedia.so on armv6hf?

[Erik De Rijcke]

Why are there limitations on the embedded port of javafx to begin with?
Are there technical reasons for it?

If you think about it, It's arm, so it's embedded. It's x86 so it's
desktop doesn't make much sense... (atom is embedded, and there are arm
windows netbooks that are not).

Anyway, as a workaround, can't openjfx simply be compiled on an arm host
(so no cross compilation is required) and as such generate the missing
libraries? Qemu with an arm vm can be used to do that on an x86 host for
example.

On Tue, Mar 17, 2015 at 12:50 PM, Fabrizio Giudici 
fabrizio.giud...@tidalwave.it wrote:

 On Tue, 17 Mar 2015 01:21:29 +0100, Felix Bembrick 
 felix.bembr...@gmail.com wrote:

  I really admire guys like this and wish that my own personal circumstances
 enabled me to get involved in a similar way but my main concern is that
 the
 community required to make JavaFX truly viable on iOS, Android and ARM
 needs to be about 50-100 times bigger than it currently is.  Without an


 It's my concern too. At this point we're at 20 years of Java, and I lived
 them from the very beginning. The idea the community will fix it is a
 déjà vu that, unfortunately, says that in the past the thing didn't work
 many times.

 This doesn't mean I'm necessarily in a fatalistic mood. When my RPI2
 arrives, I'll try the option you and others suggested.


 --
 Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
 We make Java work. Everywhere.
 http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it

Re: Build farm for OpenJFX (on ARM)

[Erik De Rijcke]

Hi David,

I've just tried to build the soft float version following the instructions
on the wiki. However when doing a 'gradle -PCOMPILE_TARGETS=armv6sf'. It
complains 'Error: missing tool packages: [arm-linaro-4.7.tgz]'.

I assume the shellscript that downloads the cross compiler tools is missing
some libraries (?). Installing 'gcc-arm-linux-gnueabi' didn't solve it
either.

Erik

On Thu, Feb 5, 2015 at 3:46 PM, David Hill david.h...@oracle.com wrote:

 On 2/5/15, 3:35 AM, Chris Newland wrote:

 Hi Chris,

   I have answering a few questions for Mani on getting a Linux  Linux ARM
 build running on the Fedora based cloudbees setup. There are still some
 packages I am missing for a full Fedora 21 build related to desktop media,
 but the core builds fine now. (Any Fedora users out there that want to help
 me find the right media development packages ?)

 Pretty excited to see this moving forward. Was dabbling last night to move
 some of the packaging steps into the Open, so that when we have a
 Cloudbees build, it will have a simple output overlay bundle.

 Glad to hear the 'Building for ARM' Wiki worked out for you. I have put a
 lot of time into the Building part of the Wiki, and am always looking for
 corrections/clarifications.

 As for treading on toes - Kevin and I are really pleased that the
 community is picking up these builds. Hopefully we can end up with a stable
 and a development bundle to point people too. There has been a lot of work
 in ARM (Monocle, touch, and 3D) that has not made it into an official ARM
 bundle.

 Open projects take a community, and it is nice to see so many of you
 helping out.

 Speaking of helping out if people want to help with contributions, we
 need a Oracle Contributor Agreement http://www.oracle.com/
 technetwork/community/oca-486395.html on file before taking code changes.

 Dave

  Hi Johan, all,

 Following the announcement that JDK builds for ARM will no longer include
 JavaFX I started talking with the OpenJDK Adoption group
 (https://wiki.openjdk.java.net/display/Adoption/Main) about the
 possibility of using their CloudBees CI system to produce OpenJFX binaries
 (for all operating systems including ARM) as a way to help keep JavaFX
 alive on IoT devices.

 For those who don't know the Adoption group, its mission is to help
 developers get started with building OpenJDK, testing new features,
 submitting bug reports, and cleaning up code.

 Adoption has a CloudBees CI set up and I've been talking with Mani Sarkar
 (@theneomatrix369) about setting up an OpenJFX CI project with
 cross-compile support that builds OpenJFX for all archs.

 The cross-compile instructions here
 https://wiki.openjdk.java.net/display/OpenJFX/Cross+
 Building+for+ARM+Hard+Float
 are working great for me locally so now we're trying to work out how to
 move that to the cloud.

 I don't want to tread on anyone's toes here and we're not trying to become
 any kind of official source for JavaFX, just trying to make sure there's
 an easy way (e.g. binaries) for end users to add JavaFX to their ARM JDKs
 and to help people dip their toes into OpenJFX development as per the
 Adoption group's mission.

 Happy to coordinate on how we can make this useful and avoid any
 duplication of effort :)

 Personally, I'm a big fan of JavaFX and use it as the UI layer in JITWatch
   (https://github.com/AdoptOpenJDK/jitwatch/). I'm also into IoT and
 wearables and think JavaFX would be great on the new Raspberry Pi 2.

 Cheers,

 Chris
 @chriswhocodes




 --
 David Hilldavid.h...@oracle.com
 Java Embedded Development

 A man's feet should be planted in his country, but his eyes should survey
 the world.
 -- George Santayana (1863 - 1952)

Re: Wayland support for JavaFX

[Erik De Rijcke]

Innitial (currently nont working) code lives at:
https://github.com/Zubnix/wayland-javafx

I do have a few questions:
 - How are you supposed to handle events coming from the display system
itself? For example, I don't see any X events being handled. How/where
should that be done?
 - How does the client rendering loop works? Like in X, in wayland you have
to flush queued op requests to the compositor. How/where should that be
done?

Erik

On Thu, Jan 29, 2015 at 10:49 PM, David Hill david.h...@oracle.com wrote:

  On 1/29/15, 4:35 PM, Erik De Rijcke wrote:

 I'll probably test it on the Weston (the Wayland reference compositor) and
 secretly also on my own compositor both running on my PC hardware. The
 thing is, Wayland clients don't really care what the hardware supports. The
 *real* egl context is set up in the compositor and with a little mesa
 trickery, is made available to the client. (see
 http://ppaalanen.blogspot.be/2012/03/what-does-egl-do-in-wayland-stack.html
 ). So the client doesn't need to know how to setup an egl context. If egl
 is unavailable or undesired, the client can/should be able to fall back to
 software rendering, which is simply done by filling a buffer with pixels
 and asking the compositor to dislay it.

  I'm having a look at the EGL-Framebuffer and Software - Framebuffer
 and at first glance seems like a very easy thing to port to Wayland (that
 is, easy as easy goes in software development...).  I'm not quite sure what
 you mean with the 'own virtual windows'. It sounds a bit like a use case
 for wayland's subsurface (
 http://ppaalanen.blogspot.be/2013/11/sub-surfaces-now.html ) which afaik
 does exactly that.

   Mesa maybe the tricky part. The software renderer has demonstrated
 shader compatability issues in the past with JFX. These are shaders that
 are happy across a range of other devices.

 It still might be interesting to try it with the software - framebuffer
 path.

 Good luck and let us appraised.

 Dave

   Erik

 On Thu, Jan 29, 2015 at 10:02 PM, David Hill david.h...@oracle.com
 wrote:

  On 1/29/15, 3:47 PM, Erik De Rijcke wrote:

 Hi all,

 I'm looking at running javafx on wayland (
 http://wayland.freedesktop.org
 ). First of all, I was wondering if anyone else knows of any attempts to
 avoid duplicate work, as for now google turns op empty.

 Secondly, I'm looking for sources on how to write a new javafx platform.
 Google points me to monocle and it's *Platform implementations. Are there
 other sources of documentation or pointers or 'must-known's?

 I already made wayland java bindings (
 https://github.com/Zubnix/wayland-java-bindings ) and wrote a simple
 wayland compositor ( https://github.com/Zubnix/westmalle ) all in pure
 Java. So the wayland part is already covered.

 Thanks in advance, I'll update this post with my progressions.


  I am not aware of anyone doing a wayland port yet. It certainly should
 be a reasonable thing to do, using Glass/Monocle, we already support a
 similar setup with EGL-Framebuffer and Software - Framebuffer.

 Glancing at your wayland-java-bindings I see mention of EGL :-)

 Note however, Monocle does its own windows virtually. Wayland was
 designed as a composition as well as a framebuffer engine. Monocle will
 want to create a mono native window which acts as our display, that we then
 render onto.

 Note that Monocle supports a number of platforms and rendering paths,
 starting in PlatformFactory.

 Which hardware are you going to try this on ?

 Dave



 Erik



 --
 David Hilldavid.h...@oracle.com david.h...@oracle.com
 Java Embedded Development

 A man's feet should be planted in his country, but his eyes should
 survey the world.
 -- George Santayana (1863 - 1952)




 --
 David Hill david.h...@oracle.com david.h...@oracle.com
 Java Embedded Development

 A man's feet should be planted in his country, but his eyes should survey 
 the world.
 -- George Santayana (1863 - 1952)

Fwd: Wayland support for JavaFX

[Erik De Rijcke]

-- Forwarded message --
From: Erik De Rijcke derijcke.e...@gmail.com
Date: Thu, Jan 29, 2015 at 10:35 PM
Subject: Re: Wayland support for JavaFX
To: David Hill david.h...@oracle.com


I'll probably test it on the Weston (the Wayland reference compositor) and
secretly also on my own compositor both running on my PC hardware. The
thing is, Wayland clients don't really care what the hardware supports. The
*real* egl context is set up in the compositor and with a little mesa
trickery, is made available to the client. (see
http://ppaalanen.blogspot.be/2012/03/what-does-egl-do-in-wayland-stack.html
). So the client doesn't need to know how to setup an egl context. If egl
is unavailable or undesired, the client can/should be able to fall back to
software rendering, which is simply done by filling a buffer with pixels
and asking the compositor to dislay it.

I'm having a look at the EGL-Framebuffer and Software - Framebuffer and
at first glance seems like a very easy thing to port to Wayland (that is,
easy as easy goes in software development...).  I'm not quite sure what you
mean with the 'own virtual windows'. It sounds a bit like a use case for
wayland's subsurface (
http://ppaalanen.blogspot.be/2013/11/sub-surfaces-now.html ) which afaik
does exactly that.

Erik


On Thu, Jan 29, 2015 at 10:02 PM, David Hill david.h...@oracle.com wrote:

 On 1/29/15, 3:47 PM, Erik De Rijcke wrote:

 Hi all,

 I'm looking at running javafx on wayland ( http://wayland.freedesktop.org
 ). First of all, I was wondering if anyone else knows of any attempts to
 avoid duplicate work, as for now google turns op empty.

 Secondly, I'm looking for sources on how to write a new javafx platform.
 Google points me to monocle and it's *Platform implementations. Are there
 other sources of documentation or pointers or 'must-known's?

 I already made wayland java bindings (
 https://github.com/Zubnix/wayland-java-bindings ) and wrote a simple
 wayland compositor ( https://github.com/Zubnix/westmalle ) all in pure
 Java. So the wayland part is already covered.

 Thanks in advance, I'll update this post with my progressions.


 I am not aware of anyone doing a wayland port yet. It certainly should be
 a reasonable thing to do, using Glass/Monocle, we already support a similar
 setup with EGL-Framebuffer and Software - Framebuffer.

 Glancing at your wayland-java-bindings I see mention of EGL :-)

 Note however, Monocle does its own windows virtually. Wayland was
 designed as a composition as well as a framebuffer engine. Monocle will
 want to create a mono native window which acts as our display, that we then
 render onto.

 Note that Monocle supports a number of platforms and rendering paths,
 starting in PlatformFactory.

 Which hardware are you going to try this on ?

 Dave



 Erik



 --
 David Hilldavid.h...@oracle.com
 Java Embedded Development

 A man's feet should be planted in his country, but his eyes should survey
 the world.
 -- George Santayana (1863 - 1952)

Wayland support for JavaFX

[Erik De Rijcke]

Hi all,

I'm looking at running javafx on wayland ( http://wayland.freedesktop.org
). First of all, I was wondering if anyone else knows of any attempts to
avoid duplicate work, as for now google turns op empty.

Secondly, I'm looking for sources on how to write a new javafx platform.
Google points me to monocle and it's *Platform implementations. Are there
other sources of documentation or pointers or 'must-known's?

I already made wayland java bindings (
https://github.com/Zubnix/wayland-java-bindings ) and wrote a simple
wayland compositor ( https://github.com/Zubnix/westmalle ) all in pure
Java. So the wayland part is already covered.

Thanks in advance, I'll update this post with my progressions.

Erik