[External] : Re: Wayland
Kevin Rushforth
kevin.rushforth at oracle.com
Mon Apr 29 22:57:00 UTC 2024
Thank you.
-- Kevin
On 4/29/2024 2:35 PM, Thiago Milczarek Sayão wrote:
> 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/
> <https://urldefense.com/v3/__https://wayland.app/protocols/__;!!ACWV5N9M2RV99hQ!Jo_TDwcs-PU92bLqkpeok4ZlEQPsXiuBR6VfTF1dPSZ9mw24pohF8OxE3mlESTQMdQw0OeOFkX-vr7oN_qyvIrSwcvY$>
>
> 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.rushforth at 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
>> <https://urldefense.com/v3/__https://github.com/tsayao/glass-wayland__;!!ACWV5N9M2RV99hQ!Jo_TDwcs-PU92bLqkpeok4ZlEQPsXiuBR6VfTF1dPSZ9mw24pohF8OxE3mlESTQMdQw0OeOFkX-vr7oN_qyvrMZe-eM$>
>>
>> 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
>> <https://urldefense.com/v3/__https://github.com/gfxstrand/wayland-java/tree/master/scanner__;!!ACWV5N9M2RV99hQ!Jo_TDwcs-PU92bLqkpeok4ZlEQPsXiuBR6VfTF1dPSZ9mw24pohF8OxE3mlESTQMdQw0OeOFkX-vr7oN_qyv70bWagY$>
>>
>> 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
>> <https://urldefense.com/v3/__https://github.com/tsayao/glass-wayland__;!!ACWV5N9M2RV99hQ!Jo_TDwcs-PU92bLqkpeok4ZlEQPsXiuBR6VfTF1dPSZ9mw24pohF8OxE3mlESTQMdQw0OeOFkX-vr7oN_qyvrMZe-eM$>
>>
>> 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
>>>> <https://urldefense.com/v3/__https://github.com/tsayao/wayland-test/blob/main/wayland-test.c__;!!ACWV5N9M2RV99hQ!Jo_TDwcs-PU92bLqkpeok4ZlEQPsXiuBR6VfTF1dPSZ9mw24pohF8OxE3mlESTQMdQw0OeOFkX-vr7oN_qyv-uSsniA$>
>>>> >
>>>> > 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/c95e6862/attachment-0001.htm>
More information about the openjfx-dev
mailing list