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.h...@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.h...@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 Hilldavid.h...@oracle.com david.h...@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.h...@oracle.com david.h...@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)
