Re: OpenGL deprecated in OS-X

I’m doing some work with Vulkan at the moment so maybe I’ll be able to help out with Vk support for JavaFX. John-Val > On 5 Jun 2018, at 17:18, Johan Vos wrote: > > Ever since Apple deprecated the developer-oriented Apple ][ , I failed to > appreciate their decisions. But so be it. > > The

Re: OpenGL deprecated in OS-X

Hi, in the light of this announcement it might be a good idea to consider ANGLE again as a unified rendering platform for JavaFX. Do not try to reinvent the wheel again. The JavaFX community is much too small to always do its

Re: OpenGL deprecated in OS-X

Ever since Apple deprecated the developer-oriented Apple ][ , I failed to appreciate their decisions. But so be it. The good thing is that the structure of the OpenJFX project allows for different rendering pipelines without much impact on other code. Therefore, I think it would be a nice sandbox

Re: Removal of apps/scenebuilder from OpenJFX repo

Sorry, I missed this question. We incorporated the changes that were in OpenJFX 9 into the butbucket repo and they are part of the Gluon Scene Builder 9 release. - Johan On Tue, Mar 13, 2018 at 10:17 PM Michael Paus wrote: > How will these changes then be synchronized with the work Gluon is

Re: Removal of apps/scenebuilder from OpenJFX repo

I wasn't entirely correct. There are 2 changesets that are not in SB9 but that will be part of SB 10: https://github.com/gluonhq/scenebuilder/commit/88f89eb674110ba62d26aec9e6683fc5577bc1ce https://github.com/gluonhq/scenebuilder/commit/a051b9e52a65b918a8711071c9afc8c08f7a3c30 - Johan On Tue,

OpenGL deprecated in OS-X

Tom's right. Major news. Presumably prism would need to cater for a third renderer, Metal. What would be the time scales for this? Is this an opportunity to update the way javafx renderer works? Perhaps a tie in to Lwjgl is better? They have Vulcan bindings and no doubt will wrap Metal. But I

Re: Removal of apps/scenebuilder from OpenJFX repo

Hi Sverre, That is true, we are moving Scene Builder to GitHub. It was a labour intensive process as we looked into PR's and issues and history etc, but it's almost done now. While the process doesn't change, we understood most developers prefer to work with github for these kinds of open-source

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

Sorry, perhaps it was I who misunderstood the debate.. On Mon, Jun 4, 2018 at 4:06 PM, Michael Paus wrote: > Maybe I misunderstood the question but to my opinion the real question is > whether the new java packager has to provide the support for a splash > screen > or not. This has nothing to

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

Yes, my only comment was that if we can get a window up using standard Java GUI frameworks fast enough, then the complexity of adding splashscreen support to the launcher isn't justified. Mario's example shows that is it 1-2 seconds to get a window up. That is a bit high. If it was under 1s then

launching JavaFX in 11

Hi, I'm a bit confused on the different options for launching JavaFX applications with the latest Java 11 code. When running an app from maven, it worked fine. Maven uses the classpath and not the module path, so I assumed that running the same app using java -cp all-javafx-jars Main would work

Re: launching JavaFX in 11

Hi Johan, The intention is to launch using --module-path     java --module-path path-to-sdk/javafx-sdk-11/lib ... For non-modular applications you also need to add the modules to the module graph, for example:     java --module-path path-to-sdk/javafx-sdk-11/lib --add-modules

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

Hi! Just for the records: My test included the JVM startup time. Yours start counting in main() where the JVM is already up - and probably some of the classpath scanning already took place because of the inheritance from „javafx.application.Application“ . Your test shows „showing: 298 shown:

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

Here's a more accurate (but still rough) timing application: import javafx.application.Application; import javafx.stage.Stage; import javafx.scene.Scene; import javafx.scene.control.*; import javafx.scene.layout.*; public class Main extends Application { private static long t1; private

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

You are right. Here's an updated version of the app that take into account the time before Main::main() is invoked. import javafx.application.Application; import javafx.stage.Stage; import javafx.scene.Scene; import javafx.scene.control.*; import javafx.scene.layout.*; public class Main extends