WebView and WebGL

[Michael Paus]

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 <johnvalrose at 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 <swpalmer at 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 <stnordstrom at 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 <info at michaelhoffer.de> wrote:
>>>>>
>>>>> Hi Jonathan, hi all,
>>>>>
>>>>> I would like to bring up the "WritableImage backed by DirectBuffer"
>>>>> discussion again:
>>>>>