Wayland
Kevin Rushforth
kevin.rushforth at oracle.com
Mon Apr 29 21:09:39 UTC 2024
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.sayao at 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
> <nlisker at 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.race at 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.race at 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
>>> <nlisker at 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.sayao at 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.rushforth at 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.
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240429/d2410fc5/attachment-0001.htm>
More information about the openjfx-dev
mailing list