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