Re: [External] : Re: Wayland

2024-04-30 Thread Kevin Rushforth 

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 
 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/



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
 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



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



Cheers

Em ter., 23 de abr. de 2024 às 09:11, Thiago Milczarek Sayão
 escreveu:

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
 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
 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 1
iterations to get code fully compiled.

java -XX:+PrintFlagsFinal -version 2>&1 | grep
CompileThreshold
 intx CompileThreshold = 1 {pd product}
{default}
    double CompileThresholdScaling = 1.00
{product} {default}
    uintx IncreaseFirstTierCompileThresholdAt =
50 {product} {default}
 intx Tier2CompileThreshold = 0 {product}
{default}

Re: [External] : Re: Wayland

2024-04-30 Thread Thiago Milczarek Sayão 
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/
> 
>
> 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
>> 
>>
>> 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
>> 
>>
>> 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
>>> 
>>>
>>> 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 
>>> 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 
 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 1 iterations to get code
> fully compiled.
>
> java -XX:+PrintFlagsFinal -version 2>&1 | grep CompileThreshold
>  intx CompileThreshold =
> 1  {pd product} {default}
> double CompileThresholdScaling  =
> 1.00  {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

Re: [External] : Re: Wayland

2024-04-29 Thread Kevin Rushforth 

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/ 



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 
 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



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



Cheers

Em ter., 23 de abr. de 2024 às 09:11, Thiago Milczarek Sayão
 escreveu:

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
 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
 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 1
iterations to get code fully compiled.

java -XX:+PrintFlagsFinal -version 2>&1 | grep
CompileThreshold
 intx CompileThreshold =
1  {pd product}
{default}
    double CompileThresholdScaling  =
1.00 {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

Re: Wayland

2024-04-29 Thread Thiago Milczarek Sayão 
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/

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
>
> 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
>
> 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
>>
>> 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 
>> 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 
>>> 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 1 iterations to get code
 fully compiled.

 java -XX:+PrintFlagsFinal -version 2>&1 | grep CompileThreshold
  intx CompileThreshold =
 1  {pd product} {default}
 double CompileThresholdScaling  =
 1.00  {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

Re: Wayland

2024-04-29 Thread Kevin Rushforth 
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

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

Cheers

Em ter., 23 de abr. de 2024 às 09:11, Thiago Milczarek Sayão 
 escreveu:


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
 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
 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 1 iterations to
get code fully compiled.

java -XX:+PrintFlagsFinal -version 2>&1 | grep
CompileThreshold
 intx CompileThreshold =
1  {pd product} {default}
    double CompileThresholdScaling = 1.00 {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
 escreveu:

As a reminder, using FFM will require all FX
*applications* to

Re: Wayland

2024-04-28 Thread Thiago Milczarek Sayão 
Hi,

I managed to display a very basic wayland toplevel surface from java:
https://github.com/tsayao/glass-wayland

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

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
>
> 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 
> 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 
>> 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 1 iterations to get code
>>> fully compiled.
>>>
>>> java -XX:+PrintFlagsFinal -version 2>&1 | grep CompileThreshold
>>>  intx CompileThreshold =
>>> 1  {pd product} {default}
>>> double CompileThresholdScaling  =
>>> 1.00  {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  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,

Re: Wayland

2024-04-23 Thread 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 
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 
> 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 1 iterations to get code fully
>> compiled.
>>
>> java -XX:+PrintFlagsFinal -version 2>&1 | grep CompileThreshold
>>  intx CompileThreshold =
>> 1  {pd product} {default}
>> double CompileThresholdScaling  =
>> 1.00  {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 
>> 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  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

Re: Wayland

2024-04-22 Thread Nir Lisker 
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  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 1 iterations to get code fully
> compiled.
>
> java -XX:+PrintFlagsFinal -version 2>&1 | grep CompileThreshold
>  intx CompileThreshold =
> 1  {pd product} {default}
> double CompileThresholdScaling  =
> 1.00  {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 
> 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  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
> >

Re: Wayland

2024-04-22 Thread Philip Race 

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 1 iterations to get code 
fully compiled.


java -XX:+PrintFlagsFinal -version 2>&1 | grep CompileThreshold
 intx CompileThreshold = 
1  {pd product} {default}
    double CompileThresholdScaling  = 
1.00  {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 
 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  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
 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
 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

Re: Wayland

2024-04-22 Thread Thiago Milczarek Sayão 
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 
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  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
 >
 > 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.


>

Re: Wayland

2024-04-22 Thread Philip Race 
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  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
 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
 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.

Re: Wayland

2024-04-22 Thread Nir Lisker 
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  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
>>> >
>>> > 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.
>>>
>>>

Re: [External] : Re: Wayland

2024-04-22 Thread Kevin Rushforth 
Your math is a bit off: it's 2 years from now, not 7. We recently bumped 
the minimum for JavaFX 23 to JDK 21. Two years from now, we will bump 
the minimum for JavaFX 27 to JDK 25.


We might consider bumping it even earlier to a non-LTS, as an exception 
to our general practice, specifically to enable Panama, given the need 
to get away from sun.misc.Unsafe (used by Marlin), so there is a 
possibility that it could be less than 2 years. That will require a some 
discussion.


-- Kevin


On 4/22/2024 7:49 AM, Thiago Milczarek Sayão 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 
 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.

Re: Wayland

2024-04-22 Thread Nir Lisker 
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
>> >
>> > 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.
>>
>>

Re: Wayland

2024-04-22 Thread Thiago Milczarek Sayão 
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
> >
> > 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.
>
>

Re: Wayland

2024-04-22 Thread Kevin Rushforth 
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.

Re: Wayland

2024-04-22 Thread Nir Lisker 
Ah, yes, opaque types are indeed unsupported:
https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md#unsupported-features.
As Jorn said there, if the API exposes methods that use opaque types, then
you wouldn't have a problem. Also, if you have the .c file where they are
defined, jextract can handle them. It could be a bit of a hack though.

I wrote a jextract GUI wrapper with JavaFX, which I tested only on Windows
for now. I will try to get the Linux and Mac versions up soon as well. I
find it very helpful compared to the command line and I think it could help
you with the complex headers there.

Note that jextract generates Java 22 compatible code, which is unusable in
JavaFX for now (we comply with Java 21).

On Mon, Apr 22, 2024 at 1:36 AM Thiago Milczarek Sayão <
thiago.sa...@gmail.com> wrote:

> I mailed the jextract list and Jorn Vernee explained that wayland use
> opaque types, which are just defined as such:
>
> struct wl_registry;
>
> I guess you just pass it around and it's defined in the internal .c file.
> Those are not supported by jextract.
>
> I'll find a way to get around it.
>
> But I've been playing with it all day, it seems very good. I was able to
> generate bindings for:
>
> GMain - for the main loop;
> GSettings - for reading settings;
> XDG Portal - for screen capture, screenshot, file dialogs
>
> It looks like this:
>
> 1) To get a setting
>
> try(var a = Arena.ofConfined()) {
> var mouseSettings = 
> g_settings_new(a.allocateUtf8String("org.gnome.desktop.interface"));
> int size = g_settings_get_int(mouseSettings, 
> a.allocateUtf8String("cursor-size"));
> g_object_unref(mouseSettings);
> return new Size(size, size);
> }
>
>
> 2) Callbacks
>
> @Override
> protected void _invokeLater(Runnable runnable) {
> MemorySegment call = GSourceFunc.allocate(p -> {
> runnable.run();
> return 0;
> }, Arena.ofAuto());
>
> g_idle_add(call, MemorySegment.NULL);
> }
>
>
> It looks correct to me, but untested.
>
> -- Thiago.
>
> Em dom., 21 de abr. de 2024 às 18:15, Nir Lisker 
> escreveu:
>
>> Can you link to where all the headers are? I found some in
>> https://gitlab.freedesktop.org/wayland/wayland/-/tree/main/src, but I
>> couldn't see where wl_registry is defined. From what I see, wl_XYZ types
>> are structs, which are supported.
>>
>> By the way, there's a new guide for jextract at
>> https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md. When
>> working with complex headers (includes upon includes), it's important to
>> specify the correct target header.
>>
>> On Sun, Apr 21, 2024 at 11:35 PM Thiago Milczarek Sayão <
>> thiago.sa...@gmail.com> wrote:
>>
>>> jextract --output src -t org.freedesktop.wayland.client
>>> --header-class-name WlClient `pkg-config --cflags-only-I wayland-client`
>>> `pkg-config --libs wayland-client`  /usr/include/wayland-client.h
>>>
>>> WARNING: Skipping wl_registry (type Declared(wl_registry) is not
>>> supported)
>>>
>>> I would need this to hook the events with wl_registry_add_listener, but
>>> currently the code generation for this is not working.
>>>
>>>
>>>
>>>
>>>
>>> Em dom., 21 de abr. de 2024 às 16:39, Nir Lisker 
>>> escreveu:
>>>
 What are wl_ types? jextract only supports c headers.

 On Sun, Apr 21, 2024 at 10:31 PM Thiago Milczarek Sayão <
 thiago.sa...@gmail.com> 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.
>

Re: Wayland

2024-04-21 Thread Thiago Milczarek Sayão 
I mailed the jextract list and Jorn Vernee explained that wayland use
opaque types, which are just defined as such:

struct wl_registry;

I guess you just pass it around and it's defined in the internal .c file.
Those are not supported by jextract.

I'll find a way to get around it.

But I've been playing with it all day, it seems very good. I was able to
generate bindings for:

GMain - for the main loop;
GSettings - for reading settings;
XDG Portal - for screen capture, screenshot, file dialogs

It looks like this:

1) To get a setting

try(var a = Arena.ofConfined()) {
var mouseSettings =
g_settings_new(a.allocateUtf8String("org.gnome.desktop.interface"));
int size = g_settings_get_int(mouseSettings,
a.allocateUtf8String("cursor-size"));
g_object_unref(mouseSettings);
return new Size(size, size);
}


2) Callbacks

@Override
protected void _invokeLater(Runnable runnable) {
MemorySegment call = GSourceFunc.allocate(p -> {
runnable.run();
return 0;
}, Arena.ofAuto());

g_idle_add(call, MemorySegment.NULL);
}


It looks correct to me, but untested.

-- Thiago.

Em dom., 21 de abr. de 2024 às 18:15, Nir Lisker 
escreveu:

> Can you link to where all the headers are? I found some in
> https://gitlab.freedesktop.org/wayland/wayland/-/tree/main/src, but I
> couldn't see where wl_registry is defined. From what I see, wl_XYZ types
> are structs, which are supported.
>
> By the way, there's a new guide for jextract at
> https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md. When
> working with complex headers (includes upon includes), it's important to
> specify the correct target header.
>
> On Sun, Apr 21, 2024 at 11:35 PM Thiago Milczarek Sayão <
> thiago.sa...@gmail.com> wrote:
>
>> jextract --output src -t org.freedesktop.wayland.client
>> --header-class-name WlClient `pkg-config --cflags-only-I wayland-client`
>> `pkg-config --libs wayland-client`  /usr/include/wayland-client.h
>>
>> WARNING: Skipping wl_registry (type Declared(wl_registry) is not
>> supported)
>>
>> I would need this to hook the events with wl_registry_add_listener, but
>> currently the code generation for this is not working.
>>
>>
>>
>>
>>
>> Em dom., 21 de abr. de 2024 às 16:39, Nir Lisker 
>> escreveu:
>>
>>> What are wl_ types? jextract only supports c headers.
>>>
>>> On Sun, Apr 21, 2024 at 10:31 PM Thiago Milczarek Sayão <
>>> thiago.sa...@gmail.com> 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.

>>>

Re: Wayland

2024-04-21 Thread Nir Lisker 
Can you link to where all the headers are? I found some in
https://gitlab.freedesktop.org/wayland/wayland/-/tree/main/src, but I
couldn't see where wl_registry is defined. From what I see, wl_XYZ types
are structs, which are supported.

By the way, there's a new guide for jextract at
https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md. When working
with complex headers (includes upon includes), it's important to specify
the correct target header.

On Sun, Apr 21, 2024 at 11:35 PM Thiago Milczarek Sayão <
thiago.sa...@gmail.com> wrote:

> jextract --output src -t org.freedesktop.wayland.client
> --header-class-name WlClient `pkg-config --cflags-only-I wayland-client`
> `pkg-config --libs wayland-client`  /usr/include/wayland-client.h
>
> WARNING: Skipping wl_registry (type Declared(wl_registry) is not supported)
>
> I would need this to hook the events with wl_registry_add_listener, but
> currently the code generation for this is not working.
>
>
>
>
>
> Em dom., 21 de abr. de 2024 às 16:39, Nir Lisker 
> escreveu:
>
>> What are wl_ types? jextract only supports c headers.
>>
>> On Sun, Apr 21, 2024 at 10:31 PM Thiago Milczarek Sayão <
>> thiago.sa...@gmail.com> 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.
>>>
>>

Re: Wayland

2024-04-21 Thread Thiago Milczarek Sayão 
jextract --output src -t org.freedesktop.wayland.client --header-class-name
WlClient `pkg-config --cflags-only-I wayland-client` `pkg-config --libs
wayland-client`  /usr/include/wayland-client.h

WARNING: Skipping wl_registry (type Declared(wl_registry) is not supported)

I would need this to hook the events with wl_registry_add_listener, but
currently the code generation for this is not working.





Em dom., 21 de abr. de 2024 às 16:39, Nir Lisker 
escreveu:

> What are wl_ types? jextract only supports c headers.
>
> On Sun, Apr 21, 2024 at 10:31 PM Thiago Milczarek Sayão <
> thiago.sa...@gmail.com> 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.
>>
>

Re: Wayland

2024-04-21 Thread Nir Lisker 
What are wl_ types? jextract only supports c headers.

On Sun, Apr 21, 2024 at 10:31 PM Thiago Milczarek Sayão <
thiago.sa...@gmail.com> 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.
>

Re: Wayland

2023-11-19 Thread Thiago Milczarek Sayão 
Hi,

Been doing some experiments.

It should be possible (and the best way to go) to use wayland-client
without gtk.

Desktop iterations should be done with libportal (such as file dialogs):
https://libportal.org/

It is possible to implement the Robot with libportal "RemoteDesktop" - in
my experiments the only downside is that it asks for permission and is only
for one monitor - but maybe should be enough for testing purposes.

The solution would still use gnome libraries such as glib and gio.
Settings can be obtained using gsettings.

-- Thiago.







Em qui., 16 de nov. de 2023 às 07:57, Thiago Milczarek Sayão <
thiago.sa...@gmail.com> escreveu:

> Hi,
>
> It seems there are some opportunities to explore with Wayland:
>
> For kiosks (Ubuntu frame):
> https://mir-server.io/
>
> https://wayland.app/protocols/
> There are some interesting extensions such as Tizen (samsung OS) and
> "In-vehicle infotainment": https://wayland.app/protocols/ivi-application
> I found it interesting because of the Wayland adoption for those scenarios.
>
> I'm doing some experiments and it seems to fit well using wayland-client
> directly.
>
> I was thinking about keeping GTK for system dialogs such as file open -
> but it can be done with DBUS and xdg-desktop-portal. So if the user is on
> KDE it will display a KDE file open dialog:
> https://flatpak.github.io/xdg-desktop-portal/docs/. Same for "Settings".
>
> xdg-desktop-portal also has interfaces for "RemoteDesktop" which I think
> can be used for Robot (to simulate as if it was using RDP and send cursor
> movements and keys).
>
>  -- Thiago
>
> Em sex., 10 de nov. de 2023 às 09:43, Thiago Milczarek Sayão <
> thiago.sa...@gmail.com> escreveu:
>
>> Hi Johan,
>>
>> Robot will be a challenge.
>>
>> For mouse and keyboard simulation this could work:
>> https://www.kernel.org/doc/html/v4.12/input/uinput.html
>>
>> of maybe:
>>
>> https://docs.flatpak.org/pt-br/latest/portal-api-reference.html#gdbus-org.freedesktop.portal.RemoteDesktop
>>
>> For screenshot:
>>
>> https://docs.flatpak.org/pt-br/latest/portal-api-reference.html#gdbus-org.freedesktop.portal.Screenshot
>>
>> Haven't tested anything yet.
>>
>> I did some experiments on the jfx-sandbox (it displays the window on
>> wayland with software rendering), but the conclusion so far is that it's
>> better to ditch gtk and use wayland-client directly, except for system
>> dialogs such as file open.
>>
>> -- Thiago.
>>
>>
>> Em sex., 10 de nov. de 2023 às 06:39, Johan Vos 
>> escreveu:
>>
>>> Hi Thiago,
>>>
>>> Thanks for the work on Wayland. I spent some time on it in the past as
>>> well, and I'll hope to find some time to look at your work soon.
>>>
>>> The main worry I had in the past was how to deal with the robot, where
>>> we need to get pixels from the screen -- did you tackle that?
>>>
>>> - Johan
>>>
>>> On Fri, Nov 3, 2023 at 1:14 AM Thiago Milczarek Sayão <
>>> thiago.sa...@gmail.com> wrote:
>>>
 Hi,

 About Wayland:

 Porting es2 to use EGL instead of GLX is pretty straightforward, so
 converting a X11GL* to WaylandGL* is easy (GLX is X11 only, so this is why
 EGL is needed).
 The problem is Gtk4 and/or Gtk3 with Wayland won't allow you to paint
 directly to the window as es2 do.
 I've tried to use Gtk4 and composite it with a GL texture - it would
 work, but does't fit well with es2 as it is designed to swapBuffers.

 I'm looking for the shortest path to get it working.

 I'm thinking now to use wayland-client directly for most things, so it
 will be possible to create the WaylandGL* infrastructure and render
 directly to a surface.
 Compositing directly with wayland would be better anyways. Using Gtk (3
 or 4) would require rendering somewhere else (other than onscreen wayland
 surface) and then composite the result with Gtk.

 So, the conclusion for now is that Gtk won't work with wayland for the
 use of another toolkit (outside of the gtk rendering scope).

 wayland-client, here I go.

 -- Thiago.









 Em sáb., 21 de out. de 2023 às 18:12, Thiago Milczarek Sayão <
 thiago.sa...@gmail.com> escreveu:

> EGL is the way to go for Linux on Wayland and X11.
>
> I don't know how to do it yet, but it seems the solution is to use
> DMABUF with EGL and share it with GTK (I suspect on a GtkGLArea widget, 
> but
> not sure yet).
>
> Firefox and WebKit GTK uses the same technic.
>
> Gtk4 does not allow application painting, so direct surface context is
> not possible.
>
> We are using gtk3 and it is still possible, but I want to use
> GtkHeaderbar and clean up glass code. Since it means sharing the
> window/surface with GTK, direct surface rendering also doesn't work.
>
>
> https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/
>
>
>

Re: Wayland

2023-11-16 Thread Thiago Milczarek Sayão 
Hi,

It seems there are some opportunities to explore with Wayland:

For kiosks (Ubuntu frame):
https://mir-server.io/

https://wayland.app/protocols/
There are some interesting extensions such as Tizen (samsung OS) and
"In-vehicle infotainment": https://wayland.app/protocols/ivi-application
I found it interesting because of the Wayland adoption for those scenarios.

I'm doing some experiments and it seems to fit well using wayland-client
directly.

I was thinking about keeping GTK for system dialogs such as file open - but
it can be done with DBUS and xdg-desktop-portal. So if the user is on KDE
it will display a KDE file open dialog:
https://flatpak.github.io/xdg-desktop-portal/docs/. Same for "Settings".

xdg-desktop-portal also has interfaces for "RemoteDesktop" which I think
can be used for Robot (to simulate as if it was using RDP and send cursor
movements and keys).

 -- Thiago

Em sex., 10 de nov. de 2023 às 09:43, Thiago Milczarek Sayão <
thiago.sa...@gmail.com> escreveu:

> Hi Johan,
>
> Robot will be a challenge.
>
> For mouse and keyboard simulation this could work:
> https://www.kernel.org/doc/html/v4.12/input/uinput.html
>
> of maybe:
>
> https://docs.flatpak.org/pt-br/latest/portal-api-reference.html#gdbus-org.freedesktop.portal.RemoteDesktop
>
> For screenshot:
>
> https://docs.flatpak.org/pt-br/latest/portal-api-reference.html#gdbus-org.freedesktop.portal.Screenshot
>
> Haven't tested anything yet.
>
> I did some experiments on the jfx-sandbox (it displays the window on
> wayland with software rendering), but the conclusion so far is that it's
> better to ditch gtk and use wayland-client directly, except for system
> dialogs such as file open.
>
> -- Thiago.
>
>
> Em sex., 10 de nov. de 2023 às 06:39, Johan Vos 
> escreveu:
>
>> Hi Thiago,
>>
>> Thanks for the work on Wayland. I spent some time on it in the past as
>> well, and I'll hope to find some time to look at your work soon.
>>
>> The main worry I had in the past was how to deal with the robot, where we
>> need to get pixels from the screen -- did you tackle that?
>>
>> - Johan
>>
>> On Fri, Nov 3, 2023 at 1:14 AM Thiago Milczarek Sayão <
>> thiago.sa...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> About Wayland:
>>>
>>> Porting es2 to use EGL instead of GLX is pretty straightforward, so
>>> converting a X11GL* to WaylandGL* is easy (GLX is X11 only, so this is why
>>> EGL is needed).
>>> The problem is Gtk4 and/or Gtk3 with Wayland won't allow you to paint
>>> directly to the window as es2 do.
>>> I've tried to use Gtk4 and composite it with a GL texture - it would
>>> work, but does't fit well with es2 as it is designed to swapBuffers.
>>>
>>> I'm looking for the shortest path to get it working.
>>>
>>> I'm thinking now to use wayland-client directly for most things, so it
>>> will be possible to create the WaylandGL* infrastructure and render
>>> directly to a surface.
>>> Compositing directly with wayland would be better anyways. Using Gtk (3
>>> or 4) would require rendering somewhere else (other than onscreen wayland
>>> surface) and then composite the result with Gtk.
>>>
>>> So, the conclusion for now is that Gtk won't work with wayland for the
>>> use of another toolkit (outside of the gtk rendering scope).
>>>
>>> wayland-client, here I go.
>>>
>>> -- Thiago.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Em sáb., 21 de out. de 2023 às 18:12, Thiago Milczarek Sayão <
>>> thiago.sa...@gmail.com> escreveu:
>>>
 EGL is the way to go for Linux on Wayland and X11.

 I don't know how to do it yet, but it seems the solution is to use
 DMABUF with EGL and share it with GTK (I suspect on a GtkGLArea widget, but
 not sure yet).

 Firefox and WebKit GTK uses the same technic.

 Gtk4 does not allow application painting, so direct surface context is
 not possible.

 We are using gtk3 and it is still possible, but I want to use
 GtkHeaderbar and clean up glass code. Since it means sharing the
 window/surface with GTK, direct surface rendering also doesn't work.


 https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/


 https://blogs.igalia.com/carlosgc/2023/04/03/webkitgtk-accelerated-compositing-rendering/

 https://blog.gtk.org/2021/05/10/adventures-in-graphics-apis/

 It's been nice to learn.

 Em seg., 16 de out. de 2023 20:51, Thiago Milczarek Sayão <
 thiago.sa...@gmail.com> escreveu:

> Hi,
>
> I am investigating about prism on Wayland.
>
> It looks like we could just replace the GLX calls on X11 backend to
> EGL and it will work on both (maybe rename it).
>
> It will need some work to pass the native display around - it assumes
> X11 Display everywhere and it could be a Display or a wl_display.
>
> -- Thiago.
>
> Em dom., 15 de out. de 2023 às 16:06, Thiago Milczarek Sayão <
> thiago.sa...@gmail.com> escreveu:
>
>> Hi,
>>

Re: Wayland

2023-11-10 Thread Thiago Milczarek Sayão 
Hi Johan,

Robot will be a challenge.

For mouse and keyboard simulation this could work:
https://www.kernel.org/doc/html/v4.12/input/uinput.html

of maybe:
https://docs.flatpak.org/pt-br/latest/portal-api-reference.html#gdbus-org.freedesktop.portal.RemoteDesktop

For screenshot:
https://docs.flatpak.org/pt-br/latest/portal-api-reference.html#gdbus-org.freedesktop.portal.Screenshot

Haven't tested anything yet.

I did some experiments on the jfx-sandbox (it displays the window on
wayland with software rendering), but the conclusion so far is that it's
better to ditch gtk and use wayland-client directly, except for system
dialogs such as file open.

-- Thiago.


Em sex., 10 de nov. de 2023 às 06:39, Johan Vos 
escreveu:

> Hi Thiago,
>
> Thanks for the work on Wayland. I spent some time on it in the past as
> well, and I'll hope to find some time to look at your work soon.
>
> The main worry I had in the past was how to deal with the robot, where we
> need to get pixels from the screen -- did you tackle that?
>
> - Johan
>
> On Fri, Nov 3, 2023 at 1:14 AM Thiago Milczarek Sayão <
> thiago.sa...@gmail.com> wrote:
>
>> Hi,
>>
>> About Wayland:
>>
>> Porting es2 to use EGL instead of GLX is pretty straightforward, so
>> converting a X11GL* to WaylandGL* is easy (GLX is X11 only, so this is why
>> EGL is needed).
>> The problem is Gtk4 and/or Gtk3 with Wayland won't allow you to paint
>> directly to the window as es2 do.
>> I've tried to use Gtk4 and composite it with a GL texture - it would
>> work, but does't fit well with es2 as it is designed to swapBuffers.
>>
>> I'm looking for the shortest path to get it working.
>>
>> I'm thinking now to use wayland-client directly for most things, so it
>> will be possible to create the WaylandGL* infrastructure and render
>> directly to a surface.
>> Compositing directly with wayland would be better anyways. Using Gtk (3
>> or 4) would require rendering somewhere else (other than onscreen wayland
>> surface) and then composite the result with Gtk.
>>
>> So, the conclusion for now is that Gtk won't work with wayland for the
>> use of another toolkit (outside of the gtk rendering scope).
>>
>> wayland-client, here I go.
>>
>> -- Thiago.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Em sáb., 21 de out. de 2023 às 18:12, Thiago Milczarek Sayão <
>> thiago.sa...@gmail.com> escreveu:
>>
>>> EGL is the way to go for Linux on Wayland and X11.
>>>
>>> I don't know how to do it yet, but it seems the solution is to use
>>> DMABUF with EGL and share it with GTK (I suspect on a GtkGLArea widget, but
>>> not sure yet).
>>>
>>> Firefox and WebKit GTK uses the same technic.
>>>
>>> Gtk4 does not allow application painting, so direct surface context is
>>> not possible.
>>>
>>> We are using gtk3 and it is still possible, but I want to use
>>> GtkHeaderbar and clean up glass code. Since it means sharing the
>>> window/surface with GTK, direct surface rendering also doesn't work.
>>>
>>>
>>> https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/
>>>
>>>
>>> https://blogs.igalia.com/carlosgc/2023/04/03/webkitgtk-accelerated-compositing-rendering/
>>>
>>> https://blog.gtk.org/2021/05/10/adventures-in-graphics-apis/
>>>
>>> It's been nice to learn.
>>>
>>> Em seg., 16 de out. de 2023 20:51, Thiago Milczarek Sayão <
>>> thiago.sa...@gmail.com> escreveu:
>>>
 Hi,

 I am investigating about prism on Wayland.

 It looks like we could just replace the GLX calls on X11 backend to EGL
 and it will work on both (maybe rename it).

 It will need some work to pass the native display around - it assumes
 X11 Display everywhere and it could be a Display or a wl_display.

 -- Thiago.

 Em dom., 15 de out. de 2023 às 16:06, Thiago Milczarek Sayão <
 thiago.sa...@gmail.com> escreveu:

> Hi,
>
> Update: It now works on wayland with -Dprism.order=sw
>
>
>
> Em dom., 15 de out. de 2023 às 10:49, Thiago Milczarek Sayão <
> thiago.sa...@gmail.com> escreveu:
>
>> Hi,
>>
>> https://github.com/openjdk/jfx-sandbox/tree/tsayao_wayland
>>
>> I did some experiments here. So far, so good.
>>
>> 1) Replaced GDK events for Gtk Signals - It's the way to go for newer
>> gtk.
>> 2) Replaced drawing directly in the window and added a GtkDrawingArea
>> with a GtkHeaderBar which allows control over the whole window
>> size and allows to get rid of extents* calls - this cleans up a lot.
>> 3) Unified the WindowContext to clean it up.
>>
>> I also integrated the IME replacement proposed here:
>> https://github.com/openjdk/jfx/pull/1080
>>
>> It almost runs with software rendering on Wayland, but something
>> still touches X11.
>>
>> To finally make it work on Wayland it requires to implement it on
>> prism es2. I see that there's a EGL part of Monocle. I still don't
>> completely understand it, but wouldn't it work as a

Re: Wayland

2023-11-10 Thread Johan Vos 
Hi Thiago,

Thanks for the work on Wayland. I spent some time on it in the past as
well, and I'll hope to find some time to look at your work soon.

The main worry I had in the past was how to deal with the robot, where we
need to get pixels from the screen -- did you tackle that?

- Johan

On Fri, Nov 3, 2023 at 1:14 AM Thiago Milczarek Sayão <
thiago.sa...@gmail.com> wrote:

> Hi,
>
> About Wayland:
>
> Porting es2 to use EGL instead of GLX is pretty straightforward, so
> converting a X11GL* to WaylandGL* is easy (GLX is X11 only, so this is why
> EGL is needed).
> The problem is Gtk4 and/or Gtk3 with Wayland won't allow you to paint
> directly to the window as es2 do.
> I've tried to use Gtk4 and composite it with a GL texture - it would work,
> but does't fit well with es2 as it is designed to swapBuffers.
>
> I'm looking for the shortest path to get it working.
>
> I'm thinking now to use wayland-client directly for most things, so it
> will be possible to create the WaylandGL* infrastructure and render
> directly to a surface.
> Compositing directly with wayland would be better anyways. Using Gtk (3 or
> 4) would require rendering somewhere else (other than onscreen wayland
> surface) and then composite the result with Gtk.
>
> So, the conclusion for now is that Gtk won't work with wayland for the use
> of another toolkit (outside of the gtk rendering scope).
>
> wayland-client, here I go.
>
> -- Thiago.
>
>
>
>
>
>
>
>
>
> Em sáb., 21 de out. de 2023 às 18:12, Thiago Milczarek Sayão <
> thiago.sa...@gmail.com> escreveu:
>
>> EGL is the way to go for Linux on Wayland and X11.
>>
>> I don't know how to do it yet, but it seems the solution is to use DMABUF
>> with EGL and share it with GTK (I suspect on a GtkGLArea widget, but not
>> sure yet).
>>
>> Firefox and WebKit GTK uses the same technic.
>>
>> Gtk4 does not allow application painting, so direct surface context is
>> not possible.
>>
>> We are using gtk3 and it is still possible, but I want to use
>> GtkHeaderbar and clean up glass code. Since it means sharing the
>> window/surface with GTK, direct surface rendering also doesn't work.
>>
>>
>> https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/
>>
>>
>> https://blogs.igalia.com/carlosgc/2023/04/03/webkitgtk-accelerated-compositing-rendering/
>>
>> https://blog.gtk.org/2021/05/10/adventures-in-graphics-apis/
>>
>> It's been nice to learn.
>>
>> Em seg., 16 de out. de 2023 20:51, Thiago Milczarek Sayão <
>> thiago.sa...@gmail.com> escreveu:
>>
>>> Hi,
>>>
>>> I am investigating about prism on Wayland.
>>>
>>> It looks like we could just replace the GLX calls on X11 backend to EGL
>>> and it will work on both (maybe rename it).
>>>
>>> It will need some work to pass the native display around - it assumes
>>> X11 Display everywhere and it could be a Display or a wl_display.
>>>
>>> -- Thiago.
>>>
>>> Em dom., 15 de out. de 2023 às 16:06, Thiago Milczarek Sayão <
>>> thiago.sa...@gmail.com> escreveu:
>>>
 Hi,

 Update: It now works on wayland with -Dprism.order=sw



 Em dom., 15 de out. de 2023 às 10:49, Thiago Milczarek Sayão <
 thiago.sa...@gmail.com> escreveu:

> Hi,
>
> https://github.com/openjdk/jfx-sandbox/tree/tsayao_wayland
>
> I did some experiments here. So far, so good.
>
> 1) Replaced GDK events for Gtk Signals - It's the way to go for newer
> gtk.
> 2) Replaced drawing directly in the window and added a GtkDrawingArea
> with a GtkHeaderBar which allows control over the whole window
> size and allows to get rid of extents* calls - this cleans up a lot.
> 3) Unified the WindowContext to clean it up.
>
> I also integrated the IME replacement proposed here:
> https://github.com/openjdk/jfx/pull/1080
>
> It almost runs with software rendering on Wayland, but something still
> touches X11.
>
> To finally make it work on Wayland it requires to implement it on
> prism es2. I see that there's a EGL part of Monocle. I still don't
> completely understand it, but wouldn't it work as a drop-in replacement?
>
> -- Thiago.
>
>
>

Re: Wayland

2023-11-02 Thread Thiago Milczarek Sayão 
Hi,

About Wayland:

Porting es2 to use EGL instead of GLX is pretty straightforward, so
converting a X11GL* to WaylandGL* is easy (GLX is X11 only, so this is why
EGL is needed).
The problem is Gtk4 and/or Gtk3 with Wayland won't allow you to paint
directly to the window as es2 do.
I've tried to use Gtk4 and composite it with a GL texture - it would work,
but does't fit well with es2 as it is designed to swapBuffers.

I'm looking for the shortest path to get it working.

I'm thinking now to use wayland-client directly for most things, so it will
be possible to create the WaylandGL* infrastructure and render directly to
a surface.
Compositing directly with wayland would be better anyways. Using Gtk (3 or
4) would require rendering somewhere else (other than onscreen wayland
surface) and then composite the result with Gtk.

So, the conclusion for now is that Gtk won't work with wayland for the use
of another toolkit (outside of the gtk rendering scope).

wayland-client, here I go.

-- Thiago.









Em sáb., 21 de out. de 2023 às 18:12, Thiago Milczarek Sayão <
thiago.sa...@gmail.com> escreveu:

> EGL is the way to go for Linux on Wayland and X11.
>
> I don't know how to do it yet, but it seems the solution is to use DMABUF
> with EGL and share it with GTK (I suspect on a GtkGLArea widget, but not
> sure yet).
>
> Firefox and WebKit GTK uses the same technic.
>
> Gtk4 does not allow application painting, so direct surface context is not
> possible.
>
> We are using gtk3 and it is still possible, but I want to use GtkHeaderbar
> and clean up glass code. Since it means sharing the window/surface with
> GTK, direct surface rendering also doesn't work.
>
>
> https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/
>
>
> https://blogs.igalia.com/carlosgc/2023/04/03/webkitgtk-accelerated-compositing-rendering/
>
> https://blog.gtk.org/2021/05/10/adventures-in-graphics-apis/
>
> It's been nice to learn.
>
> Em seg., 16 de out. de 2023 20:51, Thiago Milczarek Sayão <
> thiago.sa...@gmail.com> escreveu:
>
>> Hi,
>>
>> I am investigating about prism on Wayland.
>>
>> It looks like we could just replace the GLX calls on X11 backend to EGL
>> and it will work on both (maybe rename it).
>>
>> It will need some work to pass the native display around - it assumes X11
>> Display everywhere and it could be a Display or a wl_display.
>>
>> -- Thiago.
>>
>> Em dom., 15 de out. de 2023 às 16:06, Thiago Milczarek Sayão <
>> thiago.sa...@gmail.com> escreveu:
>>
>>> Hi,
>>>
>>> Update: It now works on wayland with -Dprism.order=sw
>>>
>>>
>>>
>>> Em dom., 15 de out. de 2023 às 10:49, Thiago Milczarek Sayão <
>>> thiago.sa...@gmail.com> escreveu:
>>>
 Hi,

 https://github.com/openjdk/jfx-sandbox/tree/tsayao_wayland

 I did some experiments here. So far, so good.

 1) Replaced GDK events for Gtk Signals - It's the way to go for newer
 gtk.
 2) Replaced drawing directly in the window and added a GtkDrawingArea
 with a GtkHeaderBar which allows control over the whole window
 size and allows to get rid of extents* calls - this cleans up a lot.
 3) Unified the WindowContext to clean it up.

 I also integrated the IME replacement proposed here:
 https://github.com/openjdk/jfx/pull/1080

 It almost runs with software rendering on Wayland, but something still
 touches X11.

 To finally make it work on Wayland it requires to implement it on prism
 es2. I see that there's a EGL part of Monocle. I still don't completely
 understand it, but wouldn't it work as a drop-in replacement?

 -- Thiago.

Re: Wayland

2023-10-21 Thread Thiago Milczarek Sayão 
EGL is the way to go for Linux on Wayland and X11.

I don't know how to do it yet, but it seems the solution is to use DMABUF
with EGL and share it with GTK (I suspect on a GtkGLArea widget, but not
sure yet).

Firefox and WebKit GTK uses the same technic.

Gtk4 does not allow application painting, so direct surface context is not
possible.

We are using gtk3 and it is still possible, but I want to use GtkHeaderbar
and clean up glass code. Since it means sharing the window/surface with
GTK, direct surface rendering also doesn't work.

https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/

https://blogs.igalia.com/carlosgc/2023/04/03/webkitgtk-accelerated-compositing-rendering/

https://blog.gtk.org/2021/05/10/adventures-in-graphics-apis/

It's been nice to learn.

Em seg., 16 de out. de 2023 20:51, Thiago Milczarek Sayão <
thiago.sa...@gmail.com> escreveu:

> Hi,
>
> I am investigating about prism on Wayland.
>
> It looks like we could just replace the GLX calls on X11 backend to EGL
> and it will work on both (maybe rename it).
>
> It will need some work to pass the native display around - it assumes X11
> Display everywhere and it could be a Display or a wl_display.
>
> -- Thiago.
>
> Em dom., 15 de out. de 2023 às 16:06, Thiago Milczarek Sayão <
> thiago.sa...@gmail.com> escreveu:
>
>> Hi,
>>
>> Update: It now works on wayland with -Dprism.order=sw
>>
>>
>>
>> Em dom., 15 de out. de 2023 às 10:49, Thiago Milczarek Sayão <
>> thiago.sa...@gmail.com> escreveu:
>>
>>> Hi,
>>>
>>> https://github.com/openjdk/jfx-sandbox/tree/tsayao_wayland
>>>
>>> I did some experiments here. So far, so good.
>>>
>>> 1) Replaced GDK events for Gtk Signals - It's the way to go for newer
>>> gtk.
>>> 2) Replaced drawing directly in the window and added a GtkDrawingArea
>>> with a GtkHeaderBar which allows control over the whole window
>>> size and allows to get rid of extents* calls - this cleans up a lot.
>>> 3) Unified the WindowContext to clean it up.
>>>
>>> I also integrated the IME replacement proposed here:
>>> https://github.com/openjdk/jfx/pull/1080
>>>
>>> It almost runs with software rendering on Wayland, but something still
>>> touches X11.
>>>
>>> To finally make it work on Wayland it requires to implement it on prism
>>> es2. I see that there's a EGL part of Monocle. I still don't completely
>>> understand it, but wouldn't it work as a drop-in replacement?
>>>
>>> -- Thiago.
>>>
>>>
>>>

Re: Wayland

2023-10-16 Thread Thiago Milczarek Sayão 
Hi,

I am investigating about prism on Wayland.

It looks like we could just replace the GLX calls on X11 backend to EGL and
it will work on both (maybe rename it).

It will need some work to pass the native display around - it assumes X11
Display everywhere and it could be a Display or a wl_display.

-- Thiago.

Em dom., 15 de out. de 2023 às 16:06, Thiago Milczarek Sayão <
thiago.sa...@gmail.com> escreveu:

> Hi,
>
> Update: It now works on wayland with -Dprism.order=sw
>
>
>
> Em dom., 15 de out. de 2023 às 10:49, Thiago Milczarek Sayão <
> thiago.sa...@gmail.com> escreveu:
>
>> Hi,
>>
>> https://github.com/openjdk/jfx-sandbox/tree/tsayao_wayland
>>
>> I did some experiments here. So far, so good.
>>
>> 1) Replaced GDK events for Gtk Signals - It's the way to go for newer gtk.
>> 2) Replaced drawing directly in the window and added a GtkDrawingArea
>> with a GtkHeaderBar which allows control over the whole window
>> size and allows to get rid of extents* calls - this cleans up a lot.
>> 3) Unified the WindowContext to clean it up.
>>
>> I also integrated the IME replacement proposed here:
>> https://github.com/openjdk/jfx/pull/1080
>>
>> It almost runs with software rendering on Wayland, but something still
>> touches X11.
>>
>> To finally make it work on Wayland it requires to implement it on prism
>> es2. I see that there's a EGL part of Monocle. I still don't completely
>> understand it, but wouldn't it work as a drop-in replacement?
>>
>> -- Thiago.
>>
>>
>>

Re: Wayland

2023-10-15 Thread Thiago Milczarek Sayão 
Hi,

Update: It now works on wayland with -Dprism.order=sw



Em dom., 15 de out. de 2023 às 10:49, Thiago Milczarek Sayão <
thiago.sa...@gmail.com> escreveu:

> Hi,
>
> https://github.com/openjdk/jfx-sandbox/tree/tsayao_wayland
>
> I did some experiments here. So far, so good.
>
> 1) Replaced GDK events for Gtk Signals - It's the way to go for newer gtk.
> 2) Replaced drawing directly in the window and added a GtkDrawingArea with
> a GtkHeaderBar which allows control over the whole window
> size and allows to get rid of extents* calls - this cleans up a lot.
> 3) Unified the WindowContext to clean it up.
>
> I also integrated the IME replacement proposed here:
> https://github.com/openjdk/jfx/pull/1080
>
> It almost runs with software rendering on Wayland, but something still
> touches X11.
>
> To finally make it work on Wayland it requires to implement it on prism
> es2. I see that there's a EGL part of Monocle. I still don't completely
> understand it, but wouldn't it work as a drop-in replacement?
>
> -- Thiago.
>
>
>