Re: Wayland support for JavaFX
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
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) > >
Fwd: Wayland support for JavaFX
-- Forwarded message -- From: Erik De Rijcke Date: Thu, Jan 29, 2015 at 10:35 PM Subject: Re: Wayland support for JavaFX To: David Hill 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. 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) > >
Re: Wayland support for JavaFX
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)
Wayland support for JavaFX
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. Erik
