Hi Paul, a while ago I started an experiment that adds shared memory based nodes to the scene graph. You can find an experimental WebKit node with full WebGL support on GitHub: https://github.com/miho/VFXWebKit Here you can see it in action: https://www.youtube.com/watch?v=FlIrY1SlNM4
As I said, it is only an experiment. As it tries to use public APIs as much as possible it is quite slow, since to my knowledge, native memory buffers cannot be used for rendering images. Hi all, I think we should definitely add the possibility to render native buffers. Following this mailing list for quite some time now, I get the impression that many of the complaints about missing features could be integrated much easier and with more community involvement. If you compare my WebKit hack with the official WebKit support, it is clear that the official version has a much tighter integration with JavaFX rendering. Updating to a newer version is very hard to achieve and consumes many resources. But for many applications, a shared memory approach is sufficient and much easier to implement. My experiment was done in just a few days. Updating to a new WebKit/Blink version works like a charm since it does not need any Java or JavaFX specific changes. Additionally, a crash in the native code keeps the JVM alive and just needs a restart of the native rendering process. That's cool, isn't it? That being said, I fully understand that the tight integration has advantages too. So it is not my intention to speak against the built-in WebView. But allowing native rendering has further benefits than integrating WebKit or Blink. Any native rendering that can render to offscreen memory will be instantly supported (JOGL, VTK, Qt and so much more!). Community members could add so many new features, such a Blink based web views, JOGL nodes and even X11 views without the need to make new JavaFX API proposals for each and every rendering technology. I also have a very personal motivation. I am actively advocating and teaching Java and JavaFX at Universities in the context of scientific computing. And I am so sad that for some things we cannot use JavaFX, e.g., for highly complex 3d visualizations. Adding native buffer/rendering support would radically change that situation. We could integrate specific scientific visualization toolkits into the JavaFX scene graph and so much more! That would be so awesome! Please check out the GitHub experiment. For shared memory on the native side I used boost shared_mem stuff. So it should also work on Windows. But currently, everything is setup to work on OS X. Anyone who supports this idea, please let's talk about potential API proposals! Regards, Michael Hoffer 2016-06-15 16:30 GMT+02:00 Kondratko, Paul <paul.kondra...@morganstanley.com >: > Hi, > > WebView that comes with JavaFX does not support WebGL. I understand from > other online posts that there is no plan to add WebGL support. > > Is anyone familiar with a webView plugin that supports WebGL? Ideally open > source. > > Thank you and Best Regards, > Paul > > > ________________________________ > > NOTICE: Morgan Stanley is not acting as a municipal advisor and the > opinions or views contained herein are not intended to be, and do not > constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall > Street Reform and Consumer Protection Act. If you have received this > communication in error, please destroy all electronic and paper copies; do > not disclose, use or act upon the information; and notify the sender > immediately. Mistransmission is not intended to waive confidentiality or > privilege. Morgan Stanley reserves the right, to the extent permitted under > applicable law, to monitor electronic communications. This message is > subject to terms available at the following link: > http://www.morganstanley.com/disclaimers If you cannot access these > links, please notify us by reply message and we will send the contents to > you. By messaging with Morgan Stanley you consent to the foregoing. > -- Dipl.-Math. Michael Hoffer Twitter: @mihosoft Webpage: www.mihosoft.eu Goethe-Zentrum für Wissenschaftliches Rechnen (G-CSC) Goethe-Universität Kettenhofweg 139 60325 Frankfurt am Main phone: +49 69 798 25254 i...@michaelhoffer.de
