Hi Wade,
one of the ideas behind DukeScript was to not create our own rendering
technology and set of widgets. That has huge benefits:
- We don't have to write and maintain a Rendering Pipeline. JavaFX proofs how
hard it is. They have huge performance problems, partially caused by basically
only using egl commands, after more than 10 years.
- Our API has about 60 classes, of which you probably touch 30 at most unless
you want to port it to a new platform. JavaFX has about 700 due to the many
widgets.
- We can use all the Widgets supported by HTML/CSS and any HTML/CSS/JavaScript
framework without any additional work. All the guys writing new JS libraries
and tools are working for us.
As a result, we can focus on porting to new platforms, making the API better,
improving testability, etc. instead of having to maintain a huge codebase. That
doesn't prevent you from providing a different rendering pipeline. We'd be more
than happy to see such development.
Regarding the architecture: In a plain DukeScript application we're starting a
normal Java process. This process starts a HTML5Renderer using a "Presenter",
e.g embedded chromium. The task of the Presenter is to take care of the
communication and make it transparent to the developer. As the Java process is
running on your local machine, you can use java.io or nio to open files.
Regarding Web APIs, I agree with Sean that not every browser out there can
handle it, but if you control the browser, you're way better off than with
JavaFX 3D, because modern browser are using fast and well maintained rendering
pipelines. Chrome, for example uses ANGLE to map commands to DirectX and
OpenGL. I think tere were discussions about using ANGLE for javaFX as well to
improve performance, but I haven't heard what came out of this.
--Toni
-----Ursprüngliche Nachricht-----
Von: Wade Chandler <wadechand...@apache.org>
Gesendet: Dienstag, 13. März 2018 15:19
An: dev@netbeans.incubator.apache.org
Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from
Oracle JDK
> On Mar 13, 2018, at 3:04 AM, <toni.ep...@eppleton.de>
> <toni.ep...@eppleton.de> wrote:
>
> Hi Wade,
>
> I agree, desktop isn't going away. At DukeScript we're using HTML4J Apis
> mainly for desktop applications. The Java Desktop Application is just using a
> HTML5-Component ("browser") to render the view instead of a native or Java
> rendering pipeline.
How are events handled then? If you want to open a file as an example? Are you
running the JVM as a separate service backend and using web services?
>
> Since the separation of view and view logic is very clean the view technology
> can be completely replaced. In some of our commercial projects we used
> Controls4J to render the view, in others plain HTML and CSS. I've got working
> prototypes that use native controls instead on iOS and Android. Even one that
> renders to JavaFX that I sometimes use for debugging.
That sounds pretty cool.
>
> And unlike Swing or JavaFX browsers are evolving at great speed and getter
> better day by day without any investment on our side. That's a great benefit
> if you compare that to the sluggish development of Swing and JavaFX that
> we've seen in the past years.
>
Perhaps, but I think one has to bind a product to a specific and embeddable
browser for something like NB and NB RCP, or perhaps some custom Webkit.
Relying on just anything seems like a lot to support at that level.
I figure if views themselves can be replaced, then technically we could have
our own native views instead. We could do some things based on OpenGL or Vulkan
https://www.khronos.org/vulkan/ <https://www.khronos.org/vulkan/> or stay
low-level yet remain in Java with LWJGL https://www.lwjgl.org
<https://www.lwjgl.org/>, and not have any browser limitations. Here’s an
example of an OpenGL based UI library https://github.com/wjakob/nanogui
<https://github.com/wjakob/nanogui>
> I think that the stuff that Sean does with the crippled JavaFX 3D API is
> amazing, but think about what he could do with a really good 3D API, like the
> many that exist for WebGL.
>
I’ll let him speak more to this, but per his talks he tried different browser
based 3D APIs, and the performance wasn’t there yet. Personally, I have seen a
lot of WebGL components get the sad face uh oh in Chrome, and not be that
stable; this on good hardware.
Wade
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
