[External] : Re: Wayland
Thiago Milczarek Sayão
thiago.sayao at gmail.com
Tue Apr 30 13:41:51 UTC 2024
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/dd44de26/attachment-0001.htm>
More information about the openjfx-dev
mailing list