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) > >
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)
