[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: Wayland support for JavaFX
From:       Erik De Rijcke <derijcke.erik () gmail ! com>
Date:       2016-09-24 21:18:42
Message-ID: CABO6FzTC5AjarFYdXJCLUi7nFAGUCF2UnnzuPmT7Kgoy7Sr6iQ () mail ! gmail ! com
[Download RAW message or body]

Heads up.

A working monocle poc is now available here:
https://github.com/udevbe/wayland-javafx

Enjoy!

Erik

On Fri, Jan 30, 2015 at 10:23 PM, Erik De Rijcke <derijcke.erik@gmail.com>
wrote:

> Innitial (currently nont working) code lives at:
> https://github.com/Zubnix/wayland-javafx
>
> I do have a few questions:
>  - How are you supposed to handle events coming from the display system
> itself? For example, I don't see any X events being handled. How/where
> should that be done?
>  - How does the client rendering loop works? Like in X, in wayland you
> have to "flush" queued op requests to the compositor. How/where should that
> be done?
>
> Erik
>
> On Thu, Jan 29, 2015 at 10:49 PM, David Hill <David.Hill@oracle.com>
> wrote:
>
>> On 1/29/15, 4:35 PM, Erik De Rijcke wrote:
>>
>> I'll probably test it on the Weston (the Wayland reference compositor)
>> and secretly also on my own compositor both running on my PC hardware. The
>> thing is, Wayland clients don't really care what the hardware supports. The
>> *real* egl context is set up in the compositor and with a little mesa
>> trickery, is made available to the client. (see http://ppaalanen.
>> blogspot.be/2012/03/what-does-egl-do-in-wayland-stack.html ). So the
>> client doesn't need to know how to setup an egl context. If egl is
>> unavailable or undesired, the client can/should be able to fall back to
>> software rendering, which is simply done by filling a buffer with pixels
>> and asking the compositor to dislay it.
>>
>> I'm having a look at the EGL->Framebuffer and Software -> Framebuffer and
>> at first glance seems like a very easy thing to port to Wayland (that is,
>> easy as easy goes in software development...).  I'm not quite sure what you
>> mean with the 'own virtual windows'. It sounds a bit like a use case for
>> wayland's subsurface ( http://ppaalanen.blogspot.be/
>> 2013/11/sub-surfaces-now.html ) which afaik does exactly that.
>>
>> Mesa maybe the tricky part. The software renderer has demonstrated shader
>> compatability issues in the past with JFX. These are shaders that are happy
>> across a range of other devices.
>>
>> It still might be interesting to try it with the software -> framebuffer
>> path.
>>
>> Good luck and let us appraised.
>>
>> Dave
>>
>> Erik
>>
>> On Thu, Jan 29, 2015 at 10:02 PM, David Hill <David.Hill@oracle.com>
>> wrote:
>>
>>> On 1/29/15, 3:47 PM, Erik De Rijcke wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'm looking at running javafx on wayland (
>>>> http://wayland.freedesktop.org
>>>> ). First of all, I was wondering if anyone else knows of any attempts to
>>>> avoid duplicate work, as for now google turns op empty.
>>>>
>>>> Secondly, I'm looking for sources on how to write a new javafx platform.
>>>> Google points me to monocle and it's *Platform implementations. Are
>>>> there
>>>> other sources of documentation or pointers or 'must-known's?
>>>>
>>>> I already made wayland java bindings (
>>>> https://github.com/Zubnix/wayland-java-bindings ) and wrote a simple
>>>> wayland compositor ( https://github.com/Zubnix/westmalle ) all in pure
>>>> Java. So the wayland part is already covered.
>>>>
>>>> Thanks in advance, I'll update this post with my progressions.
>>>>
>>>
>>> I am not aware of anyone doing a wayland port yet. It certainly should
>>> be a reasonable thing to do, using Glass/Monocle, we already support a
>>> similar setup with EGL->Framebuffer and Software -> Framebuffer.
>>>
>>> Glancing at your wayland-java-bindings I see mention of EGL :-)
>>>
>>> Note however, Monocle does its own "windows" virtually. Wayland was
>>> designed as a composition as well as a framebuffer engine. Monocle will
>>> want to create a mono native window which acts as our display, that we then
>>> render onto.
>>>
>>> Note that Monocle supports a number of platforms and rendering paths,
>>> starting in PlatformFactory.
>>>
>>> Which hardware are you going to try this on ?
>>>
>>> Dave
>>>
>>>
>>>
>>>> Erik
>>>>
>>>
>>>
>>> --
>>> David Hill<David.Hill@Oracle.com> <David.Hill@Oracle.com>
>>> Java Embedded Development
>>>
>>> "A man's feet should be planted in his country, but his eyes should
>>> survey the world."
>>> -- George Santayana (1863 - 1952)
>>>
>>>
>>
>>
>> --
>> David Hill <David.Hill@Oracle.com> <David.Hill@Oracle.com>
>> Java Embedded Development
>>
>> "A man's feet should be planted in his country, but his eyes should survey the world."
>> -- George Santayana (1863 - 1952)
>>
>>
>
[prev in list] [next in list] [prev in thread] [next in thread]