Thanks Michael - yes I have, and, extensively evaluated it. It's major problem is that it is a *heavyweight* component using native Chromium rendering. It's fast, supports WebGL but doesn't play nicely with the lightweight JavaFX controls. Anything rendered on top of it for example will not be visible.
It's not a valid swap-in for lightweight WebView. They offer a lightweight "mode" for JxBrowser but all it does is render into an offscreen buffer and then use that as an image in JavaFX. It's very slow, maxes-out CPU utilisation and they had to implement an event handler delegate (which is feature deficient), and... it doesn't support WebGL in this mode!!! We need to add WebGL support to a lightweight Web View (be it based on WebKit or Chromium) > On 8 Sep 2017, at 21:15, Michael Paus <m...@jugs.org> wrote: > > I can't give you any more feedback than to say that I'd very much appreciate > such an effort. > Are you aware of this project/product? https://www.teamdev.com/jxbrowser > Michael > >> Am 08.09.17 um 12:54 schrieb John-Val Rose: >> This is a genuinely serious issue and a genuinely sincere offer of helping >> as much as I can. >> >> Some response would be greatly appreciated... >> >>> On 6 Sep 2017, at 16:53, John-Val Rose <johnvalr...@gmail.com> wrote: >>> >>> Getting back to the original issue, it's good to know that work is being >>> done to implement WebGL support but I fear that the whole process will take >>> longer than is really needed. >>> >>> As I see it, JavaFX has one major competitor which is Qt. Naturally JavaFX >>> lags behind Qt in features and performance as they basically had a 20 year >>> head start! >>> >>> But they do have a WebView with WebGL support and very advanced 3D features >>> in general (like a 3D Canvas). For JavaFX, it looks as though the 3D >>> features have been "unofficially deprecated" as no enhancements are planned >>> for JFX 10 and the existing features are rudimentary at best. >>> >>> But... just getting WebView to support WebGL instantly gives JavaFX >>> advanced 3D features via the multitude of WebGL libraries such as three.js >>> etc. and the urgency for a dedicated 3D Canvas would be greatly reduced. >>> >>> Further, Chromium (as used by Qt) is about to support WebGL 2 so the gulf >>> is widening at a rapid pace. >>> >>> Could someone please try to answer the following questions so I can get a >>> better handle on where we are and what needs to be done: >>> >>> 1. Why wasn't WebGL support implemented from day zero given that WebKit >>> supports it? >>> >>> 2. Is there some significant technical issue that makes WebGL >>> implementation particularly difficult? >>> >>> 3. What is a brief overview of the work that needs to be done? >>> >>> I ask because (as I said), I am willing to work on this feature with as >>> much spare time as I can find and am keen to get going ASAP. >>> >>> And it's not just a WebGL problem per se as the current WebView only >>> supports Google Maps (one of the world's top websites) in Lite Mode which >>> again limits the potential quite badly. >>> >>> I hope these issues are related and can be addressed simultaneously. >>> >>> Ultimately, I think it will be "fatal" if we have to wait another 4 years >>> or so for Java 10 to get features that are already well developed in the >>> competitor products. >>> >>> Graciously, >>> >>> John-Val Rose >>> Rosethorn Technology >>> >>>> On 26 Aug 2017, at 23:46, Scott Palmer <swpal...@gmail.com> wrote: >>>> >>>> +1 >>>> >>>> ... to Any high performance way to get images from native code to the >>>> screen in a JavaFX app. I filed an enhancement request many years ago for >>>> a method to supply portions of the media pipeline for the media player >>>> APIs. >>>> >>>> I've also been asking for some way to get at a native surface context. Be >>>> it DirectX, OpenGL, Metal,... even just a native window handle. >>>> >>>> >>>> Scott >>>> >>>>> On Aug 26, 2017, at 9:15 AM, Sten Nordstrom <stnordst...@gmail.com> wrote: >>>>> >>>>> Hi Michael, all, >>>>> >>>>> Just want to state my support for Michael's "Direct backed WritableImage". >>>>> Having a way to do natively-backed rendering is IMO the most important >>>>> feature still missing from FX. This is an area where QT is still way ahead >>>>> with it's OpenGL/OpenGL ES integration. >>>>> >>>>> Having something like a direct-WritableImage implementation would also >>>>> make >>>>> it easier to implement a video viewer using native decoder libs. >>>>> Personally >>>>> I find this approach much more powerful than the existing FX 3D and media >>>>> streaming features, which are (especially 3D) limited in their >>>>> capabilities. >>>>> >>>>> I will be at JavaOne this year, so if there is any interest in meeting up >>>>> and talking JavaFX I'm in! >>>>> >>>>> Best regards, >>>>> >>>>> Sten Nordström >>>>> >>>>>> On Fri, 25 Aug 2017 at 22.41 Michael Hoffer <i...@michaelhoffer.de> >>>>>> wrote: >>>>>> >>>>>> Hi Jonathan, hi all, >>>>>> >>>>>> I would like to bring up the "WritableImage backed by DirectBuffer" >>>>>> discussion again: >>>>>> >
