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
Re: TableView API, no lazy retrieval of visible cell content possible?
I have filed https://javafx-jira.kenai.com/browse/RT-39917 for this in Jira. On Wed, Jan 28, 2015 at 5:57 PM, Robert Krüger wrote: > > > On Wed, Jan 28, 2015 at 5:55 PM, Robert Krüger > wrote: > >> OK, I investigated some more. >> >> What is weird is that the same table cell instance (I checked the Object >> hashcode) is set to different model values while it is still visible, i.e. >> I get sequences like this in the log, just when I display the table: >> >> Updating cell 673139775 from null with Image reference for Row 0 >> Adding Row 0 to image load queue >> Updating cell 673139775 from Image reference for Row 0 with Image >> reference for Row 1 >> Adding Row 1 to image load queue >> Dequeueing image for Row 0 >> Updating cell 673139775 from Image reference for Row 1 with Image >> reference for Row 2 >> Adding Row 2 to image load queue >> Dequeueing image for Row 1 >> Updating cell 673139775 from Image reference for Row 2 with Image >> reference for Row 3 >> Adding Row 3 to image load queue >> Dequeueing image for Row 2 >> Updating cell 673139775 from Image reference for Row 3 with Image >> reference for Row 4 >> Adding Row 4 to image load queue >> Dequeueing image for Row 3 >> Updating cell 673139775 from Image reference for Row 4 with Image >> reference for Row 5 >> Adding Row 5 to image load queue >> Dequeueing image for Row 4 >> Updating cell 673139775 from Image reference for Row 5 with Image >> reference for Row 6 >> Adding Row 6 to image load queue >> Dequeueing image for Row 5 >> >> This means that I cannot rely on the same table cell to be used for >> displaying the content while its row is visible (+ a bit of buffered rows >> around the visible area) and that means the whole approach will not work. >> >> It would really be great if someone from Oracle could comment here. None >> of this behaviour is documented in the API so it seems that using this is >> really relying on implementation details and I have found any other options >> to achieve that. The behaviour of the application as it is >> > > this should be "I have _not_ found ..." > > >> now is that randomly some images are never loaded, because they are >> quickly removed from the load queue because the cell's content is >> overwritten while it is still being displayed. >> >> >> -- Robert Krüger Managing Partner Lesspain GmbH & Co. KG www.lesspain-software.com