I thought about possible legal conflicts. The code is on my github - I'm exploring and testing before starting the real work.
wayland-scanner generates code from the protocol specs, which are xml files. https://wayland.app/protocols/ I will write a new generator/scanner from scratch - it's not too much work. The generator/scanner itself does not necessarily need to be part of the PR, but it might be a good idea to include it, since the protocol changes over time. -- Thiago. Em seg., 29 de abr. de 2024 às 18:10, Kevin Rushforth < kevin.rushfo...@oracle.com> escreveu: > As a reminder, contributors must not include 3rd-party code in any openjdk > repo. Per the terms of the OCA, all code that you contribute to OpenJDK > must be your own code. This includes code you push to openjdk/jfx-sandbox > and code in a branch of a personal fork of openjdk/jfx from which you > create a PR. > > -- Kevin > > > On 4/28/2024 2:45 PM, Thiago Milczarek Sayão wrote: > > Hi, > > I managed to display a very basic wayland toplevel surface from java: > https://github.com/tsayao/glass-wayland > > If you are using intellij, just run the "Test App" (with java 22). > > generate.sh will jextract the code from wayland-client. > > I rushed to get the window displayed - so it doesn't look good yet (but I > do accept suggestions). > > It uses a java wayland-scanner (included) to read protocol xml files and > generate code that uses jextracted calls. > > The sample also binds EGL and GL apis, but just because wayland requires a > buffer to display the surface. Maybe it was easier to use a shared memory :) > > Credits to (I adapted it to ouput jextract compatible code): > https://github.com/gfxstrand/wayland-java/tree/master/scanner > > Cheers > > Em ter., 23 de abr. de 2024 às 09:11, Thiago Milczarek Sayão < > thiago.sa...@gmail.com> escreveu: > >> I'm doing some work here: >> https://github.com/tsayao/glass-wayland >> >> So far it's been a good experience to use FFM / jextract. >> >> The idea is to plug it as a glass wayland backend when it's good enough. >> >> >> >> Em seg., 22 de abr. de 2024 às 16:16, Nir Lisker <nlis...@gmail.com> >> escreveu: >> >>> Not sure it helps with warmup, but marking a foreign function as >>> critical can improve performance: >>> https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/foreign/Linker.Option.html#critical(boolean) >>> . >>> >>> On Mon, Apr 22, 2024 at 10:02 PM Philip Race <philip.r...@oracle.com> >>> wrote: >>> >>>> No, it wasn't. I didn't even use jextracted code. >>>> The startup cost is around initialisation of FFM - around 70 ms (IIRC) >>>> overhead on my MacBook >>>> Then creation of VarHandles and MethodHandles - 2-5 ms each is what I >>>> measured, so do these lazily if you can. >>>> And warmup cost is that it takes about 10000 iterations to get code >>>> fully compiled. >>>> >>>> java -XX:+PrintFlagsFinal -version 2>&1 | grep CompileThreshold >>>> intx CompileThreshold = >>>> 10000 {pd product} {default} >>>> double CompileThresholdScaling = >>>> 1.000000 {product} {default} >>>> uintx IncreaseFirstTierCompileThresholdAt = >>>> 50 {product} {default} >>>> intx Tier2CompileThreshold = >>>> 0 {product} {default} >>>> intx Tier3CompileThreshold = >>>> 2000 {product} {default} >>>> intx Tier4CompileThreshold = >>>> 15000 {product} {default} >>>> >>>> -phil. >>>> >>>> >>>> On 4/22/24 11:45 AM, Thiago Milczarek Sayão wrote: >>>> >>>> I think the startup time might be related to all static symbol lookups. >>>> So I'm manually including just what is needed: >>>> >>>> jextract --output src -t com.sun.glass.wayland.extracted \ >>>> --header-class-name GlassWayland \ >>>> `pkg-config --libs glib-2.0 gio-2.0 libportal wayland-client` \ >>>> `pkg-config --cflags-only-I glib-2.0 gio-2.0 libportal wayland-client` \ >>>> glass-wayland.h \ >>>> --include-function xdp_portal_initable_new \ >>>> --include-function xdp_session_close \ >>>> --include-function xdp_portal_open_file \ >>>> --include-function xdp_portal_open_file_finish \ >>>> --include-function g_object_unref \ >>>> --include-function g_timeout_add \ >>>> --include-function g_add_idle \ >>>> --include-function g_main_loop_run \ >>>> --include-function g_main_loop_new \ >>>> --include-function g_main_loop_ref \ >>>> --include-function g_main_loop_unref \ >>>> --include-function g_main_loop_quit \ >>>> --include-function g_settings_new \ >>>> --include-function g_settings_get_int \ >>>> --include-function wl_display_connect \ >>>> --include-function wl_display_disconnect \ >>>> --include-function wl_display_roundtrip \ >>>> --include-function wl_display_dispatch_pending \ >>>> --include-typedef GAsyncReadyCallback \ >>>> --include-typedef GSourceFunc \ >>>> --include-typedef GError >>>> >>>> >>>> Em seg., 22 de abr. de 2024 às 13:24, Philip Race < >>>> philip.r...@oracle.com> escreveu: >>>> >>>>> As a reminder, using FFM will require all FX *applications* to specify >>>>> --enable-native-access on the command line >>>>> Although this is likely coming to JNI soon too. >>>>> >>>>> https://docs.oracle.com/en/java/javase/21/core/restricted-methods.html >>>>> >>>>> But one thing to watch out for with FFM is startup + warm up time. >>>>> I struggled a lot with that in using FFM for just one library in the >>>>> java.desktop module. >>>>> >>>>> -phil >>>>> >>>>> On 4/22/24 9:12 AM, Nir Lisker wrote: >>>>> >>>>> Sorry, we bumped to Java 21 in JavaFX 22 I think since we preserve the >>>>> N-1 rule. >>>>> >>>>> On Mon, Apr 22, 2024 at 6:03 PM Nir Lisker <nlis...@gmail.com> wrote: >>>>> >>>>>> I think that we'll be able to bump to Java 25 in JavaFX 25, like we >>>>>> did with 21. I suggested initially to bump to Java 22 exactly for FFM as >>>>>> it's very useful for JavaFX, but was told we shouldn't since it's not an >>>>>> LTS version. >>>>>> >>>>>> I have no idea how long the work on Wayland will take including the >>>>>> code review (a rather long process), but you should be able to request >>>>>> code >>>>>> reviews with FFM and have it ready for integration by Java 25. >>>>>> >>>>>> On Mon, Apr 22, 2024 at 5:49 PM Thiago Milczarek Sayão < >>>>>> thiago.sa...@gmail.com> wrote: >>>>>> >>>>>>> I was just experimenting, but it seems to be less work than going >>>>>>> with JNI. >>>>>>> If I am correct, the next Java LTS will be 25, which will be >>>>>>> required on JavaFX 29 to be released on September/29. >>>>>>> >>>>>>> It's 7 years - that's really too much. >>>>>>> >>>>>>> Maybe it's still worthwhile to prototype using FFM and then port >>>>>>> everything to JNI. >>>>>>> >>>>>>> -- Thiago. >>>>>>> >>>>>>> >>>>>>> Em seg., 22 de abr. de 2024 às 11:21, Kevin Rushforth < >>>>>>> kevin.rushfo...@oracle.com> escreveu: >>>>>>> >>>>>>>> Note also that we cannot use Panama in the JavaFX internals yet, >>>>>>>> since >>>>>>>> the minimum version of the JDK is 21. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> On 4/21/2024 10:51 AM, Thiago Milczarek Sayão wrote: >>>>>>>> > Hi, >>>>>>>> > >>>>>>>> > I did a small test app to explore Wayland client and portals (for >>>>>>>> > Robot and dialogs such as file open/save). >>>>>>>> > >>>>>>>> > https://github.com/tsayao/wayland-test/blob/main/wayland-test.c >>>>>>>> > >>>>>>>> > It seems it will work as a glass backend, but some walls will be >>>>>>>> hit >>>>>>>> > on the way :) >>>>>>>> > >>>>>>>> > I have tried to use jextract (from project Panama) to work >>>>>>>> directly >>>>>>>> > with java, but it seems it does not support wl_ types. >>>>>>>> > >>>>>>>> > -- Thiago. >>>>>>>> >>>>>>>> >>>>> >>>> >
