Re: OpenGL deprecated in OS-X
Unfortunately Apple is doing exactly what Microsoft did during the “Great API Wars”. During this time, MS decided to go with its own exclusive graphics API namely Direct 3D as part of their whole DirectX technology instead of the obvious approach of supporting OpenGL fully. These days, GPU drivers for DirectX work much better on Windows than those for OpenGL. The same will now apply for Metal drivers versus OpenGL drivers on MacOS. This is all about “vendor lock-in” and can be seen with other technologies like WebKit and Blink for example. Of course this is bad news for the developers but devs are not the core market for Windows, Apple or Google/Android hardware. The bright light on the horizon is Vulkan from Khronos which started out life as OpenGL 5 but is now being pushed as the ultimate cross platform graphics API. Even Microsoft have jumped on board and Vulkan driver support on Windows is good. We will have to wait and see but having a situation where OpenGL, DirectX, Metal and Vulkan are all important graphics APIs simultaneously is clearly not tenable. > On 5 Jun 2018, at 06:51, Tom Schindl wrote: > > 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
Re: OpenGL deprecated in OS-X
Apple has been making noises about this for a while. I wouldn't expect them to drop OpenGL in the very near future, but it would seem that investigating a Metal pipeline for FX is timely. -- Kevin On 6/4/2018 1:51 PM, Tom Schindl wrote: 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
Re: Removal of apps/scenebuilder from OpenJFX repo
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 : > > 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 : > > 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 > > > > > > > >> > >
OpenGL deprecated in OS-X
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
Re: Draft JEP for new Packaging Tool (replacement for javapackager)
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
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
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
Re: Draft JEP for new Packaging Tool (replacement for javapackager)
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,
Re: Draft JEP for new Packaging Tool (replacement for javapackager)
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 > 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
Re: Draft JEP for new Packaging Tool (replacement for javapackager)
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
Re: Draft JEP for new Packaging Tool (replacement for javapackager)
The problem is not the Java window, but the dependencies. If that window is created by a class that requires resolving other classes and somehow one of these classes take a long time to initialize, it will be slow. - Johan On Mon, Jun 4, 2018 at 12:53 PM Scott Palmer wrote: > If a Java window appears in less than half a second there is no point in > adding the complexity of a native splash screen. > > Scott > > > On Jun 4, 2018, at 5:13 AM, Tom Schindl > wrote: > > > > A splash screen has to be that instant that it IMHO makes no sense to > > time how long it takes to get the JVM and JavaFX up and running because > > it can never be as instant as a splash has to show up. > > > > Tom > > > >> On 04.06.18 01:06, Scott Palmer wrote: > >> Has anyone actually timed how long it takes to get a Java window on > screen? I don’t think the delay is long enough to bother with a splash > screen these days. > >> > >> Scott > >> > >>> On Jun 3, 2018, at 4:22 AM, Tom Schindl > wrote: > >>> > >>> That's why I requested that since a long time from the packager because > >>> a splash has to be part of the native launcher created. > >>> > >>> The Eclipse-RCP-Launcher does exactly the right thing: > >>> * Show a static image (IIRC they use bmp) > >>> * Once the VM and UI-Toolkit is up replace that image with a window > (SWT > >>> calls it Shell) so that you can go interactive showing videos, > >>> a progressbar, ... > >>> > >>> Tom > >>> > On 03.06.18 10:11, Mario Ivankovits wrote: > A preloader/splash-screen will/should also hide the JVM startup time. > > Best regards, > Mario > > > > Am 03.06.2018 um 09:57 schrieb Tom Schindl < > tom.schi...@bestsolution.at>: > > > > On 01.06.18 19:42, Johan Vos wrote: > >> I'm not saying a preloader is really a requirement, but I know of a > few > >> applications that are using it and benefiting from it. > >> > >> The preloader functionality is more than just a splash screen, and > I see > >> this valuable for instance when static initializers of classes that > are > >> used in the main class may take a lot of time. > > > > Then I'd argue that you can easily refactor your main-class ;-) > > > > Tom > >
Re: Draft JEP for new Packaging Tool (replacement for javapackager)
If a Java window appears in less than half a second there is no point in adding the complexity of a native splash screen. Scott > On Jun 4, 2018, at 5:13 AM, Tom Schindl wrote: > > A splash screen has to be that instant that it IMHO makes no sense to > time how long it takes to get the JVM and JavaFX up and running because > it can never be as instant as a splash has to show up. > > Tom > >> On 04.06.18 01:06, Scott Palmer wrote: >> Has anyone actually timed how long it takes to get a Java window on screen? >> I don’t think the delay is long enough to bother with a splash screen these >> days. >> >> Scott >> >>> On Jun 3, 2018, at 4:22 AM, Tom Schindl wrote: >>> >>> That's why I requested that since a long time from the packager because >>> a splash has to be part of the native launcher created. >>> >>> The Eclipse-RCP-Launcher does exactly the right thing: >>> * Show a static image (IIRC they use bmp) >>> * Once the VM and UI-Toolkit is up replace that image with a window (SWT >>> calls it Shell) so that you can go interactive showing videos, >>> a progressbar, ... >>> >>> Tom >>> On 03.06.18 10:11, Mario Ivankovits wrote: A preloader/splash-screen will/should also hide the JVM startup time. Best regards, Mario > Am 03.06.2018 um 09:57 schrieb Tom Schindl : > > On 01.06.18 19:42, Johan Vos wrote: >> I'm not saying a preloader is really a requirement, but I know of a few >> applications that are using it and benefiting from it. >> >> The preloader functionality is more than just a splash screen, and I see >> this valuable for instance when static initializers of classes that are >> used in the main class may take a lot of time. > > Then I'd argue that you can easily refactor your main-class ;-) > > Tom
Re: Draft JEP for new Packaging Tool (replacement for javapackager)
A splash screen has to be that instant that it IMHO makes no sense to time how long it takes to get the JVM and JavaFX up and running because it can never be as instant as a splash has to show up. Tom On 04.06.18 01:06, Scott Palmer wrote: > Has anyone actually timed how long it takes to get a Java window on screen? I > don’t think the delay is long enough to bother with a splash screen these > days. > > Scott > >> On Jun 3, 2018, at 4:22 AM, Tom Schindl wrote: >> >> That's why I requested that since a long time from the packager because >> a splash has to be part of the native launcher created. >> >> The Eclipse-RCP-Launcher does exactly the right thing: >> * Show a static image (IIRC they use bmp) >> * Once the VM and UI-Toolkit is up replace that image with a window (SWT >> calls it Shell) so that you can go interactive showing videos, >> a progressbar, ... >> >> Tom >> >>> On 03.06.18 10:11, Mario Ivankovits wrote: >>> A preloader/splash-screen will/should also hide the JVM startup time. >>> >>> Best regards, >>> Mario >>> >>> Am 03.06.2018 um 09:57 schrieb Tom Schindl : On 01.06.18 19:42, Johan Vos wrote: > I'm not saying a preloader is really a requirement, but I know of a few > applications that are using it and benefiting from it. > > The preloader functionality is more than just a splash screen, and I see > this valuable for instance when static initializers of classes that are > used in the main class may take a lot of time. Then I'd argue that you can easily refactor your main-class ;-) Tom >>>
