Re: Wayland support for JavaFX

2016-09-24 Thread Erik De Rijcke
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 
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 
> 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 
>> 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 
>>> 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  
>> Java Embedded Development
>>
>> "A man's feet should be planted in his country, but his eyes should survey 
>> the world."
>> -- George Santayana (1863 - 1952)
>>
>>
>


Re: Wayland support for JavaFX

2015-01-30 Thread Erik De Rijcke
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  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 
> 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 
>> 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  
> Java Embedded Development
>
> "A man's feet should be planted in his country, but his eyes should survey 
> the world."
> -- George Santayana (1863 - 1952)
>
>


Re: Wayland support for JavaFX

2015-01-29 Thread David Hill

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
Java Embedded Development

"A man's feet should be planted in his country, but his eyes should survey the 
world."
-- George Santayana (1863 - 1952)