Hi Neil, Emi and others, 

thanks for the constructive answers. I agree for NB we need to find an 
alternative to the current presenters. I also think with Browser, iOS and 
Android we've already proven to be capable of using anything you throw at us as 
a renderer 😉. CEF/Chromium would be an option (New BSD as far as I know, is 
that compatible). Although I think it's more important at the moment to focus 
on getting some Proof of Concept, as Geertjan proposed, working ASAP.

I wanted to avoid going that path, but if a Swing compatibility layer is really 
required - and Emi made some strong arguments here- we should consider working 
on that as well. 

More tomorrow.

Best Regards

Toni



 

-----Ursprüngliche Nachricht-----
Von: Neil C Smith <neilcsm...@apache.org> 
Gesendet: Mittwoch, 14. März 2018 09:49
An: dev@netbeans.incubator.apache.org
Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from 
Oracle JDK

Hi Toni,

On Wed, 14 Mar 2018, 07:35 , <toni.ep...@eppleton.de> wrote:

> 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.


Thanks for the info, and you know I'm sold on this approach, at least for some 
uses.

But a big question, which is what I'm trying to get to - do we have a simple, 
Apache license compatible and robust way to build and deploy such a thing cross 
platform?  And JavaFX doesn't count! ;-)  And if not, how do we get there?

If we had that, and the tooling in the IDE using our own framework to do that, 
I think we'd have a powerful (and unique?) offering amongst Java IDE's.

Note that I'm mainly considering standalone applications built with the IDE 
there - I think we need to separate that out a little from thoughts of the 
future of the IDE, although it might help prove whether that approach is at all 
feasible.

I'm less keen on the selective HTML-ifying of the IDE using JavaFX.  If that's 
no longer shipped with the JDK but retains its current license we may even have 
difficulties using what we have under Apache?

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.
>

That Web GL is faster than JavaFX doesn't entirely surprise me, but it's also 
noticeably slower than using a direct OpenGL binding with JOGL or LWJGL.  And 
at least the latter is also getting Vulkan support.

We do like our bloated abstractions in the Java world, but sometimes bare metal 
is still the way to go! :-)

Best wishes,

Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org


---------------------------------------------------------------------
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



Reply via email to