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 would advocate avoiding a naive object wrapper that privatises all wrapped calls. Imo. The problem is, currently, if a dev needs lower level access it's all shielded.
On Mon, 4 Jun 2018, 23:02 , <openjfx-dev-requ...@openjdk.java.net> wrote: > Send openjfx-dev mailing list submissions to > openjfx-dev@openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev > or, via email, send a message with subject or body 'help' to > openjfx-dev-requ...@openjdk.java.net > > You can reach the person managing the list at > openjfx-dev-ow...@openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openjfx-dev digest..." > > > Today's Topics: > > 1. Re: Draft JEP for new Packaging Tool (replacement for > javapackager) (Pedro Duque Vieira) > 2. Re: Draft JEP for new Packaging Tool (replacement for > javapackager) (Scott Palmer) > 3. Re: Draft JEP for new Packaging Tool (replacement for > javapackager) (Michael Paus) > 4. Re: Draft JEP for new Packaging Tool (replacement for > javapackager) (Mario Ivankovits) > 5. OpenGL deprecated in OS-X (Tom Schindl) > 6. Re: Removal of apps/scenebuilder from OpenJFX repo (Sverre Moe) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 4 Jun 2018 15:44:55 +0100 > From: Pedro Duque Vieira <pedro.duquevie...@gmail.com> > To: OpenJFX Mailing List <openjfx-dev@openjdk.java.net> > Subject: Re: Draft JEP for new Packaging Tool (replacement for > javapackager) > Message-ID: > < > caaeud6za5jlngbsvsaw0d-mlwnreq2y6mmtqyrvxuvsuoex...@mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hi, > > I agree with Johan and others, a splash screen is valuable and needed. > > Microsoft applications that run on Windows itself (think Word, Excel, etc), > they have a splash screen, Intelllij has a splash screen (it's swing based > AFAIK), etc.. If a Microsoft application running on its own operating > system needs a splash screen then chances are pretty high that there will > be Java apps that'll need a splash screen. > > Cheers, > > > -- > Pedro Duque Vieira > > > ------------------------------ > > Message: 2 > Date: Mon, 4 Jun 2018 12:22:18 -0400 > From: Scott Palmer <swpal...@gmail.com> > To: OpenJFX Mailing List <openjfx-dev@openjdk.java.net> > Subject: Re: Draft JEP for new Packaging Tool (replacement for > javapackager) > Message-ID: <536bf700-3f7b-42d2-9cd9-21ef9385c...@gmail.com> > Content-Type: text/plain; charset=utf-8 > > Nobody is arguing against splash screens. I?m simply suggesting that the > JVM startup is not slow enough that we need special handling of this in > native code. > > If Java can get a window displayed in under half a second there is no need > for the added complexity to support a native splash screen in the launcher. > > The idea that cinit code *can* be slow is not really the issue here unless > it isn?t possible to get a window displayed quickly even when there is no > significant initialization other than to get that window= shown. Don?t put > heavy initialization in the main class when you want a splash screen. Use > a pre-main class that shows the splash screen and calls the ?real? main > class. > > It makes sense to understand if we have this problem before making a > complex solution. > > Scott > > > > On Jun 4, 2018, at 10:44 AM, Pedro Duque Vieira < > pedro.duquevie...@gmail.com> wrote: > > > > Hi, > > > > I agree with Johan and others, a splash screen is valuable and needed. > > > > Microsoft applications that run on Windows itself (think Word, Excel, > etc), > > they have a splash screen, Intelllij has a splash screen (it's swing > based > > AFAIK), etc.. If a Microsoft application running on its own operating > > system needs a splash screen then chances are pretty high that there will > > be Java apps that'll need a splash screen. > > > > Cheers, > > > > > > -- > > Pedro Duque Vieira > > > > ------------------------------ > > Message: 3 > Date: Mon, 4 Jun 2018 18:35:15 +0200 > From: Michael Paus <m...@jugs.org> > To: OpenJFX <openjfx-dev@openjdk.java.net> > Subject: Re: Draft JEP for new Packaging Tool (replacement for > javapackager) > Message-ID: <99ace730-ad9b-f8ba-dd35-c2cf56b99...@jugs.org> > Content-Type: text/plain; charset=utf-8; format=flowed > > 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 do with the question whether applications > should > have a splash screen or not because if we find that todays Java is fast > enough > to display a simple window in less than a second or so, then the Java GUI > (Swing or JavaFX) could provide a splash screen itself. There is then no > need > for an additional mechanism provided my the packager. > > Am 04.06.18 um 16:44 schrieb Pedro Duque Vieira: > > Hi, > > > > I agree with Johan and others, a splash screen is valuable and needed. > > > > Microsoft applications that run on Windows itself (think Word, Excel, > etc), > > they have a splash screen, Intelllij has a splash screen (it's swing > based > > AFAIK), etc.. If a Microsoft application running on its own operating > > system needs a splash screen then chances are pretty high that there will > > be Java apps that'll need a splash screen. > > > > Cheers, > > > > > > > > ------------------------------ > > Message: 4 > Date: Mon, 4 Jun 2018 16:43:06 +0000 > From: Mario Ivankovits <ma...@datenwort.at> > To: Scott Palmer <swpal...@gmail.com> > Cc: OpenJFX Mailing List <openjfx-dev@openjdk.java.net> > Subject: Re: Draft JEP for new Packaging Tool (replacement for > javapackager) > Message-ID: <624b18b0-7d00-45b3-8a1a-51213bdff...@datenwort.at> > Content-Type: text/plain; charset="utf-8" > > Hi! > > I?ve just test with this very small JavaFX Application: > > public class TstFx extends Application > { > @Override > public void start(Stage primaryStage) throws Exception > { > Label root = new Label("test"); > Scene scene = new Scene(root, 800, 600); > primaryStage.setOnShown(evt -> System.exit(1)); > > primaryStage.setScene(scene); > primaryStage.show(); > } > > public static void main(String[] args) > { > launch(args); > } > } > > As you can see, the program forcibly exits once the stage is shown. So, > using ?time? I can simply measure the time required until the stage should > be visible on screen. > > Starting this with an incredible huge classpath (the one we have to use in > production) I get this times: > real 0m1.885s > user 0m3.372s > sys 0m0.433s > > Using a really small classpath I can come down to: > real 0m1.639s > user 0m2.208s > sys 0m0.297s > > > MacBook late 2016. > > The ?user" difference seems to be just because of the classpath scanning. > No static initialization happening, because this TstFx does not reference > any other class. > > Best regards, > Mario > > > Am 04.06.2018 um 18:22 schrieb Scott Palmer <swpal...@gmail.com<mailto: > swpal...@gmail.com>>: > > Nobody is arguing against splash screens. I?m simply suggesting that the > JVM startup is not slow enough that we need special handling of this in > native code. > > If Java can get a window displayed in under half a second there is no need > for the added complexity to support a native splash screen in the launcher. > > The idea that cinit code *can* be slow is not really the issue here unless > it isn?t possible to get a window displayed quickly even when there is no > significant initialization other than to get that window= shown. Don?t put > heavy initialization in the main class when you want a splash screen. Use > a pre-main class that shows the splash screen and calls the ?real? main > class. > > It makes sense to understand if we have this problem before making a > complex solution. > > Scott > > > On Jun 4, 2018, at 10:44 AM, Pedro Duque Vieira < > pedro.duquevie...@gmail.com<mailto:pedro.duquevie...@gmail.com>> wrote: > > Hi, > > I agree with Johan and others, a splash screen is valuable and needed. > > Microsoft applications that run on Windows itself (think Word, Excel, etc), > they have a splash screen, Intelllij has a splash screen (it's swing based > AFAIK), etc.. If a Microsoft application running on its own operating > system needs a splash screen then chances are pretty high that there will > be Java apps that'll need a splash screen. > > Cheers, > > > -- > Pedro Duque Vieira > > > > ------------------------------ > > Message: 5 > Date: Mon, 4 Jun 2018 22:51:56 +0200 > From: Tom Schindl <tom.schi...@bestsolution.at> > To: openjfx-dev@openjdk.java.net > Subject: OpenGL deprecated in OS-X > Message-ID: <f87a920a-081a-4e5d-b3b0-551f295bd...@bestsolution.at> > Content-Type: text/plain; charset=utf-8 > > Hi, > > I don?t know what the Apple guys are smoking but they just deprecated > OpenGL. The question is what does this mean for JavaFX. > > See https://developer.apple.com/macos/whats-new/ > > Tom > > Von meinem iPhone gesendet > > ------------------------------ > > Message: 6 > Date: Tue, 5 Jun 2018 00:01:54 +0200 > From: Sverre Moe <sverre....@gmail.com> > To: openjfx-dev@openjdk.java.net > Subject: Re: Removal of apps/scenebuilder from OpenJFX repo > Message-ID: > <CALAJ+5AG8x= > cpf+uxba3j+x0o1kmeej0sq7cs0s-j4-3pfp...@mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Looks like Gluon has moved SceneBuilder from Bitbucket for GitHub. > https://github.com/gluonhq/scenebuilder > I like this move. GitHub is much better to work with. > > > Den fre. 27. apr. 2018 kl. 13:31 skrev Sverre Moe <sverre....@gmail.com>: > > > > I would like to hear from Gluon about their work on SceneBuilder. > > Do they have any plans for improve on SceneBuilder, both bug fixed and > > new features? > > > > I guess Gluon only work on their own fork of SceneBuilder, but do they > > send changes back to the OpenJFX repository? > > > > We have migrated our application from Swing to JavaFX and have thus > > begun to use SceneBuilder. I therefor hope it will be actively > > maintained further. > > > > How can we the community contribute to the continued development of > > SceneBuilder. > > Should we work against the OpenJFX SceneBuilder or the Gluon > SceneBuilder? > > https://bitbucket.org/gluon-oss/scenebuilder > > > https://github.com/javafxports/openjdk-jfx/tree/develop/apps/scenebuilder > > > > /Sverre > > > > > > 2018-03-13 22:11 GMT+01:00 Kevin Rushforth <kevin.rushfo...@oracle.com>: > > > That will be a question for Gluon. > > > > > > -- Kevin > > > > > > > > > > > > Michael Paus wrote: > > >> > > >> How will these changes then be synchronized with the work Gluon is > doing > > >> for the version > > >> distributed by them? Do they work on the same repo? > > >> > > >> Am 12.03.18 um 23:25 schrieb Kevin Rushforth: > > >>> > > >>> Hi Florian, > > >>> > > >>> By way of update, after thinking about this for a week (and getting > some > > >>> offline feedback), I no longer propose doing this -- at least not > for the > > >>> short-mid term. I've retargeted this RFE to tbd_major and lowered the > > >>> priority to P4. > > >>> > > >>> Having said that, we don't have any plans to modify SceneBuilder, but > > >>> will happily accept contributions. > > >>> > > >>> -- Kevin > > >>> > > >>> > > >>> Florian Brunner wrote: > > >>>> > > >>>> OK, this still comes a bit as a surprise as the source code has been > > >>>> kept in the repo and was not just provided as a ZIP file. > > >>>> > > >>>> I'm currently working on a tool based on the SceneBuilder Kit. I > needed > > >>>> to work on the code a bit and was planning to donate the code back > to > > >>>> OpenJFX once released, as I was under the impression OpenJFX would > serve as > > >>>> the master / upstream-repo for all SceneBuilder forks. I was also > under the > > >>>> impression that OpenJFX at least would make sure the code works > with any new > > >>>> JDK / JavaFX version and hoped it would get support for new > controls, if any > > >>>> were added to JavaFX. > > >>>> > > >>>> -Florian > > >>>> > > >>>> Am Freitag, 2. M?rz 2018, 09:12:15 CET schrieb Kevin Rushforth: > > >>>>> > > >>>>> I filed the following JBS isuse to remova the SceneBuilder sources > from > > >>>>> the OpenJFX repo. > > >>>>> > > >>>>> https://bugs.openjdk.java.net/browse/JDK-8198961 > > >>>>> > > >>>>> As mentioned in the Description of that issue, the OpenJFX repo > > >>>>> contains the source code for a no-longer-maintained version of the > > >>>>> SceneBuilder tool. Active development on SceneBuilder in the > OpenJFX repo > > >>>>> was stopped over three years ago. Since that time, the only > changes have > > >>>>> been either jigsaw-related changes to keep it buildable and > runnable, or > > >>>>> global changes that happened to touch some of the files in > > >>>>> apps/scenebuilder. > > >>>>> > > >>>>> A fork of SceneBuilder is maintained by Gluon, so anyone wanting > to get > > >>>>> the latest SceneBuilder should go there. > > >>>>> > > >>>>> Before I proceed, I wanted to poll the list to see whether anyone > has a > > >>>>> concern with this. I don't plan to take any action for at least a > week. > > >>>>> > > >>>>> -- Kevin > > >>>>> > > >>>>> > > >>>> > > >>>> > > >> > > > > > > End of openjfx-dev Digest, Vol 79, Issue 6 > ****************************************** >
