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.rushfo...@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.rushfo...@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.sa...@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
<nlis...@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.r...@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.r...@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
<nlis...@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.sa...@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.rushfo...@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.
