Wayland

[Thiago Milczarek Sayão]

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/20240423/32ed969d/attachment-0001.htm>