how about JavaFX section in Game APIs & Engines

Business and Project Management Discussions
#21

I agree that desktop applications are getting less and less relevant, but the browser isn’t going to replace them completely any time soon.
For a lot of applications, it simply doesn’t make that much sense to run them on ‘the cloud’ (god I hate that term) and seeing Java is still a hugely popular platform there will still be a place for Swing and JavaFX.

EDIT:
“The look and feel does not match the operating system. (e.g. The filechooser… oh god.)”
The same thing can be said for Google Chrome. Or any HTML5 front-end for that matter. Personally I think there has been put too much importance in this argument over the years.

#22

Oh no, the future will be extremely slow with HTML5, 2 FPS to display a teapot with an Nvidia Quadro FX 5000 (able to treat about 1 billion triangles per second) even with the latest driver and the latest stable version of Mozilla Firefox… I prefer Java :wink:

I use Swing, SWT and Eclipse RCP every day, I don’t think it is just good for the trash bin.

#23

And also, the native L&F of Swing very, very closely matches that of the OS. Well, Windows, anyway. Close enough that I don’t care. Then again I like to switch to a custom L&F anyway.

… the JVM seems to start up pretty quickly for me, too. At least so quick that I don’t notice it being slow.

… and I don’t think MS Office will be going anywhere anytime soon with risible offerings such as Google Docs to compete with it. MS Office has only got to worry about OpenOffice or LibreOffice in reality.

Cas :slight_smile:

#24

For me the thing is, developing for “the future” is almost as bad as developing for the past. You will still have the same problem that your applications are not quite in sync with the present.
Case in point: Apple didn’t really want a native SDK when they released the first iPhone because the vision was that iPhone apps would be cloud/HTML5 apps. Yet here we are; Apple still released their SDK and native iOS apps make billions.

Let’s just take HTML5 for what it is: A great progression of HTML4. Nothing less, nothing more.

#25

atm I have to write some GUI applications with WPF(Windows Presentation Forms, C#, .NET) and even if it has some major drawbacks(language, xml nightmare, magic) it has some nice features.

Writing the GUI in some DSL(here XML) is nice, but the biggest and most interesting feature are DataBindings. Something which I now miss in Java Swing, but I think that it is included in JavaFX?

#26

It is.

#27

[quote]“The look and feel does not match the operating system. (e.g. The filechooser… oh god.)”
The same thing can be said for Google Chrome. Or any HTML5 front-end for that matter.
[/quote]
General purpose GUI isn’t a problem – often, a non-standard layout/UI can improve workflow, visual hierarchy, etc.

But when you require the user to interact with their operating system, as is the case with file choosers, it should behave as natively as possible. I cringe every time I use an application with a custom file chooser (i.e. any Swing application).

[quote]Oh no, the future will be extremely slow with HTML5, 2 FPS to display a teapot with an Nvidia Quadro FX 5000 (able to treat about 1 billion triangles per second) even with the latest driver and the latest stable version of Mozilla Firefox… I prefer Java
[/quote]
Call me a visionary… but I suspect we’ll see some performance increases in the next few years. :stuck_out_tongue:

Besides, we’re talking about GUI applications, not hardware accelerated real-time 3D rendering. (And, for the record, generally a 3D teapot in HTML5/WebGL will blow Swing/JavaFX out of the water.)

[quote]And also, the native L&F of Swing very, very closely matches that of the OS. Well, Windows, anyway. Close enough that I don’t care. Then again I like to switch to a custom L&F anyway.
[/quote]
I agree that Swing doesn’t look so bad on Windows. On Mac, though, the difference between native apps and Swing apps is night and day. File chooser being one of my biggest irks.

[quote]… the JVM seems to start up pretty quickly for me, too. At least so quick that I don’t notice it being slow.
[/quote]
I’ve been working with PyQt a lot, and I’ve been very impressed by its “responsiveness.” Double-clicking a PyQt application opens the GUI immediately (even though the code is interpreted and the GUI is generated using a “ui” file). Whereas all of the Swing apps I’ve tried on Windows and Mac have a short delay after double-clicking the JAR.

This might be a Swing startup issue rather than a JVM startup issue. Or maybe I’m just crazy…

#28

[quote]General purpose GUI isn’t a problem – often, a non-standard layout/UI can improve workflow, visual hierarchy, etc.
[/quote]
So generally you’d agree a Swing GUI (or any other non-native GUI) isn’t a problem too in itself.
JFileChooser is a bit of a corner-case in my opinion. Yes, JFileChooser sort of sucks, but you hardly ever see one. And if you consider we’ll be saving our stuff more and more often on the web anyway, this will become even less of an issue.

[quote]This might be a Swing startup issue rather than a JVM startup issue. Or maybe I’m just crazy…
[/quote]

[quote]Call me a visionary… but I suspect we’ll see some performance increases in the next few years.
[/quote]
Yes, Java/Swing applications start up slower. But QT nor Python is going to solve that if these applications are java for good reasons (like NetBeans, Eclipse or JVisualVM).
And besides, on my new laptop that has a nice and fast SSD, java startup-time isn’t really an issue anymore. These performance increases you talk about work for java too, you know :slight_smile:

#29

Call me a visionary… but I suspect we’ll see some performance increases in the next few years. :stuck_out_tongue:

Besides, we’re talking about GUI applications, not hardware accelerated real-time 3D rendering. (And, for the record, generally a 3D teapot in HTML5/WebGL will blow Swing/JavaFX out of the water.)
[/quote]
I don’t call you a visionary, you’re as blind as those bloggers who write ultra-indulgent articles about HTML5 and WebGL. I already explained that HTML5 canvas and WebGL are still slow on lots of machines, the latter is tricky to use except with Google Chrome (I cannot use it anymore with Chromium), even the software rendering is dead slow, I get only between 5 and 15 FPS with “Runestone Defense” (which is a quite good game) just to see tens of sprites. We have been waiting for these performance increases for years, come down to Earth. Java is not perfect but it is a mature platform. I agree with Erikd, see HTML5 as an evolution of HTML4, not something miraculous. If you don’t like JFileChooser, use AWT FileDialog.

#30

Good ol’ gouessej spreading FUD again. Just because nothing ever works on your setup doesn’t mean the whole world is broken.

Funny that I was just reading this: Multi-Optics: HTML5 3D Modeling app

#31

FUD??? I spoke about this problem to Kenneth Bradley Russell in person during a dinner at Los Angeles when I went to Siggraph 2012, Sven and Xerxes can confirm. He argued that he can’t test on all machines and that WebGL has to do a lot more things than an applet, he spoke about compositing, he said that the web browser is in your way, that it is not simple to optimize, we spoke about typed arrays, … Moreover, I tested on several machines with updated drivers, not only on a single setup. Therefore, I advise you to learn to read (I have never written that I had tested exclusively on a single setup) and to get more reliable information before accusing me of spreading FUD. I tested with at least 4 different graphics cards (Nvidia Quadro FX 5000, Nvidia Geforce 7600 GT, ATI Radeon 9250 Pro, ATI Radeon X1950 Pro). Even someone here under Windows confirmed having some jittery with RunField which is not a very complicated AAA game. The creator of Runestone Defense who use HTML5 wrote that:

[quote]I agree that the processor / GPU needed to play an HTML5 game at decent performance is stupid insane
[/quote]
Actually, he is more aware of HTML5 lack of speed than you. I spent several days to write my article and the situation is worse now, Chromium refuses to run any WebGL application since I use an ATI Radeon X1950 Pro (most of drivers for ATI graphics cards under Linux are blacklisted by Google).

Edit.: You really disappoint me, I spent so much time in writing my article about WebGL, I thought that you would read it carefully instead of accusing me of fud.

Edit.2: I saw Teamup at Siggraph.

Edit.3: My problem with LWJGL came from the frequency. If you use another display mode with the same frequency than the previous one, I don’t get any straight line in my task bar, otherwise my desktop and this bar become very dirty. This “bug” is reproducible with any native windowing toolkit (including NEWT).

#32

FUD = generalizations like “omg 2 fps to display a teapot, WebGL sucks”. You don’t need to lecture me about Javascript’s shortcomings, I know more about it than you think.

ps. It’s noone’s fault you test with shitty blacklisted drivers. I’m on AMD/Firefox too and I can run different WebGL samples in a dozen tabs without any problems.
ps2. What makes you think I read any of your articles?

#33

On topic, JavaFX 2.2 has been released (JDK7u6 as well), with support for Linux, H.264 video and touch events/gestures.

#34

I understand the sentiment of what you’re trying to say there Julien but it’s a brand new technology that’s going to take a bit of time to work out. Absolutely you’re right in that it’s not mainstream end user tech yet (with IE not supporting it, it simply can’t be, let alone all the broken drivers out there). However what it’s aiming to do is pretty laudable and a worthy cause. Who knows, maybe Javascript will get 5x faster over the next decade like Java did, in which case it’s all down to crappy drivers, and if there ever was incentive for driver writers to get their stuff working properly for once, it’d be ubiquitous desktop deployment of webGL.

Still hate Javascript mind and wish it would go away. Biggest single mistake the Web has made evar.

Cas :slight_smile:

#35

Hmm licensed H264 video playback. Finally. That seals the deal!

Spasi - perhaps JavaFX is the solution to LWJGL/OSX/Java7 display woes?

Cas :slight_smile:

#36

Hmm also there’s JDK7 on ARM to download, as well as OSX!

Cas :slight_smile:

#37

JavaFX’s renderer is not as fast as pure OpenGL, but its new faster and lighter applet plugin could most likely provide potential for a way to ‘hook’ an OpenGL context onto a ‘canvas’ like LWJGL did with AWT?

#38

[quote]So generally you’d agree a Swing GUI (or any other non-native GUI) isn’t a problem too in itself.
JFileChooser is a bit of a corner-case in my opinion. Yes, JFileChooser sort of sucks, but you hardly ever see one. And if you consider we’ll be saving our stuff more and more often on the web anyway, this will become even less of an issue.
[/quote]
File choosers appear in almost every software – it’s the standard means of loading and saving data. The fact that such a fundamental component is crappy is a big issue.

FileDialog (not Swing, which is what we’re discussing) is indeed more OS compliant, though hardly any Java apps choose to use it over JFileChooser. Hell, even NetBeans seems to use the ugly JFileChooser.

There are some other minor quirks – like not being able to search menu bar items on Mac (you need a bit of set up to get it working – most developers won’t ever bother), and the general feeling of the GUI being “off” (Mac software design is generally extremely consistent from one app to the next).

[quote]Yes, Java/Swing applications start up slower. But QT nor Python is going to solve that if these applications are java for good reasons (like NetBeans, Eclipse or JVisualVM).
And besides, on my new laptop that has a nice and fast SSD, java startup-time isn’t really an issue anymore. These performance increases you talk about work for java too, you know
[/quote]
There are plenty of IDEs not created in Swing (or Java for that matter). Eclipse uses SWT which is a great and very natural Java GUI, IMO.

VisualVM isn’t exactly your average type of software – although that, too, may have been better off not using Swing. The GUI is sluggish and unresponsive on my Mac. Granted, it’s got a lot going on, but you wonder whether a more optimal GUI toolkit would help its situation…

Regarding H264 playback with JavaFX… Damn, that’s nice.

#39

My favorite part about WebGL is how it’s going to expose whatever driver bugs are out there to arbitrary code off the internet. And in kernel mode at that. You really think they write 3d graphics drivers with security in mind?

#40

If javaFX really support h264 WELL :point: then it worth to learn.