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. WebKit drawing is routed via the FX rendering layer, which is in turn an abstraction over OpenGL and Direct3D on Windows. Mapping OpenGL to Direct3D is a tricky problem that requires a sophisticated rendering layer. In order to make WebGL happen, Google had to do a deal with a company called TransGaming that had developed a translation layer between OpenGL and Direct3D. That layer is called ANGLE and Google open sourced it once they had acquired the rights. https://chromium.googlesource.com/angle/angle/+/master/README.md To support OpenGL in Java, you have two choices: 1) Directly expose the operating system underlying OpenGL driver. 2) Emulate GL on top of whatever the OS provides. Whenever you see OpenGL being used in Java today, the path taken is (1). The reason browsers use the rather odd and indirect path of number (2) is that on Windows OpenGL is not the native drawing layer, unlike MacOS and Linux, games do not typically use OpenGL and as such the GL drivers are often low quality, low performance and buggy. The GL driver situation is so poor that it is basically never a good idea to use anything other than DirectX on Windows. I suspect this is why JavaFX uses a dedicated Direct3D backend on Windows: http://grepcode.com/file/repo1.maven.org/maven2/net.java.openjfx.backport/openjfx-78-backport/1.8.0-ea-b96.1/com/sun/prism/d3d/D3DPipeline.java > 2. Is there some significant technical issue that makes WebGL > implementation particularly difficult? > Yes. See above. > 3. What is a brief overview of the work that needs to be done? > To expose WebGL, you have to do what Chrome does and map GL to Direct3D using ANGLE. That's probably a fairly major engineering effort and requires the complete import of a new open source subsystem into FX. Note that if you do this, it'd be silly to restrict it to WebGL in WebView! You might as well expose a new JavaFX control that implements eGL at the same time, as a first step towards competing the work. That in turn would reduce the demand for WebGL because once you can do low level 3D graphics from Java directly, you don't need to go through WebKit. It'd only be needed for sites like Maps. 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. > See the recent announcement by the lead Java architect that they want to speed up Java releases. They definitely don't want a 4 year wait for Java 10: https://mreinhold.org/blog/forward-faster I'd suggest getting started by exploring ANGLE and reading their documentation and presentation materials. The path to WebGL or any form of GL in JavaFX lies through ANGLE.
