[External] : Re: Wayland
Kevin Rushforth
kevin.rushforth at oracle.com
Tue Apr 30 13:48:23 UTC 2024
Thanks.
-- Kevin
On 4/30/2024 6:41 AM, Thiago Milczarek Sayão wrote:
> Hi,
>
> I rewrote the scanner, so it's all my own code now. No legal issues
> since I signed the OCA.
>
> Generated java code looks like this:
> https://github.com/tsayao/glass-wayland/blob/main/src/com/sun/glass/wayland/extracted/XdgToplevel.java
>
>
> -- Thiago.
>
> Em seg., 29 de abr. de 2024 às 19:57, Kevin Rushforth
> <kevin.rushforth at oracle.com> escreveu:
>
> 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/20240430/1d37c834/attachment-0001.htm>
More information about the openjfx-dev
mailing list