WebView and WebGL
johnvalrose at gmail.com
Sat Sep 9 22:45:43 UTC 2017
Yes Scott, the rendering in WebView is done with the JavaFX API which has pros and cons.
The major "pro" is that it is a lightweight control that plays nicely with all other controls (and the performance is surprisingly good). The "con" is that implementing WebGL was thus very complicated (with the issues about OpenGL on Windows already mentioned) and therefore omitted.
As I mentioned in another post, the product "JxBrowser" which is based on Chromium is a heavyweight control where all the rendering is done by Chromium itself. This makes it perform just as well as Chrome and supports WebGL and full-mode Google Maps.
It looks like a great choice until you want to use other (lightweight) controls with it. The native rendering will just override anything you do over the top of JxBrowser and that age-old problem of trying to mix heavyweight and lightweight controls is highlighted.
But, if you just want a real HTML5 browser control in your JavaFX app surrounded by normal controls, it works great (if you can afford it!). But it isn't portable to iOS or Android either with tools like Gluon Mobile.
It is NOT the correct, long-term solution to enabling proper, advanced OpenGL support in JavaFX, either in a 3D Canvas or in WebView.
Determining the best solution & making it work is now my mission :-)
(And yes, the current JavaFX 3D features are extremely rudimentary and not particularly useful. I don't expect them to be ever enhanced. They're effectively "frozen". It's a harsh call but I think they were a mistake from day one. We need a completely different alternative).
> On 10 Sep 2017, at 08:16, Scott Palmer <swpalmer at gmail.com> wrote:
> If I’m remembering correctly, I think the another factor for why WebGL wasn’t included is that the rendering layer of WebKit was done on top of JavaFX. That allows it to integrate nicely with the all the other JavaFX rendering.
> Personally I wish that time wasn’t wasted (IMO) on the existing 3D support and instead proper OpenGL support was done for JavaFX - *outside* of WebKit. I think that might have required solving another problem - integrating a native rendering surface into the scene graph. That would have allowed me to solve other problems, such as showing realtime video from a camera or other image sources, that the existing media API doesn’t support.
> My issue requesting extensible media support is coming up on its 9-year anniversary:
> (It’s closed now as it is marked as a duplicate of issues that were created later, even though those issues don’t adequately cover what is required.)
> Frankly I have very little use for WebKit in a JavaFX application (other than for displaying help pages or something). If I’m going to make a web app, I will just make a web app. JavaFX would only serve to make a web app less accessible. I would of course never make a web app where a proper desktop app is more appropriate, because they always suck compared to apps that aren’t crippled by running in a browser. :-)
>> On Sep 9, 2017, at 11:06 AM, Mike Hearn <mike at plan99.net> wrote:
>> I'm not on the FX team, but I'd suggest just starting work on it and see how far you get. You might duplicate some of the research the FX engineers are doing but you also might not, or you might find yourself being able to influence the direction of the project with unique input.
>> If you can make WebGL work in WebKit, I guess it's not much harder to expose an eGL binding via JavaFX itself as WebGL is basically eGL for the web.
>> I'd like to see GL support in JavaFX, if only because I enjoy blinging apps I write, including business apps! The embedded video player is invaluable for this sort of thing too.
>> 1. Why wasn't WebGL support implemented from day zero given that WebKit supports it?
>> I am going to take a stab at these answers based on my relatively poor understanding of how JavaFX works. Answers worth what you paid for them.
>> I'm going to guess that the answer is Windows.
More information about the openjfx-dev