Re: Wayland
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
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
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: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v20]
On Sun, 24 Mar 2024 12:13:08 GMT, Thiago Milczarek Sayao wrote: >> Thiago Milczarek Sayao has updated the pull request with a new target base >> due to a merge or a rebase. The pull request now contains 94 commits: >> >> - Merge branch 'master' into new_ime >> - Add signals to avoid warnings >> - Merge branch 'master' into new_ime >> >># Conflicts: >># modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp >> - Add check for jview >> - - Fix comment path >> - - Fix double keyrelease >> - - Use a work-around to relative positioning (until wayland is not >> officially supported) >>- Unref pango attr list >> - Merge branch 'master' into new_ime >> - Account the case of !filtered >> - Fix change of focus when on preedit + add filter on key release >> - ... and 84 more: https://git.openjdk.org/jfx/compare/1fb56e33...eb988565 > > Would be nice if IME users could provide feedback on this. I can provide test > binaries if necessary. @tsayao Thank you very much, this PR is very useful. We are developers from non-English speaking countries and are looking forward to this PR very much. - PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2068195355
Re: Wayland
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
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. >
[jfx17u] Integrated: 8330682: Change JavaFX release version to 17.0.12 in jfx17u
On Fri, 19 Apr 2024 13:32:14 GMT, Johan Vos wrote: > Increase JavaFX release version to 17.0.12 This pull request has now been integrated. Changeset: 685b18e3 Author:Johan Vos URL: https://git.openjdk.org/jfx17u/commit/685b18e3625019307d437e38964a0e83ff26b801 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8330682: Change JavaFX release version to 17.0.12 in jfx17u Reviewed-by: jpereda - PR: https://git.openjdk.org/jfx17u/pull/189
Re: RFR: 8322964: Optimize performance of CSS selector matching [v9]
On Mon, 11 Mar 2024 16:54:25 GMT, John Hendrikx wrote: >> Improves performance of selector matching in the CSS subsystem. This is done >> by using custom set implementation which are highly optimized for the most >> common cases where the number of selectors is small (most commonly 1 or 2). >> It also should be more memory efficient for medium sized and large >> applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only >> introduced to assign a fixed bit index for each unique style class name >> encountered, is no longer needed. This is because style classes are no >> longer stored in a `BitSet` which required a fixed index per encountered >> style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors >> and styles from a large pool of potential styles (a `BitSet` for potentially >> 1000 different style names needed 1000 bits (worst case) as it was not >> sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read >> only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the >> inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to >> convert them to `StyleClass` and put them into a `Set`) -- this copy could >> not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which >> displays about 800 nodes on its start page with about 1000 styles in various >> style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the >> improvements in this PR, the fastest refresh had become 89 ms. The speed >> improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up >> the bulk of the time to refresh the JFXCentral main page (about 100 ms >> before vs 70 ms after the change). > > John Hendrikx has updated the pull request incrementally with one additional > commit since the last revision: > > Move getStyleClassNames to location it was introduced to reduce diff I think this is ready to be integrated. Let me know if there is anything still missing. - PR Comment: https://git.openjdk.org/jfx/pull/1316#issuecomment-2068166905
Wayland
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: Possible leak on setOnAction
I think the leaks (seems to be more than one) happens on:
ContextMenuContent.disposeVisualItems
There are visual items holding references.
They seem to be on MenuItemContainer
It looks like its held on:
mouseEnteredEventHandler
mouseReleasedEventHandler
actionEventHandler
And somewhere else I didn't find.
That's my theory for now.
Em sáb., 20 de abr. de 2024 às 10:47, Thiago Milczarek Sayão <
thiago.sa...@gmail.com> escreveu:
> Yeah, I've been doing some investigating.
>
> Using the below example, when the "Refresh Menu" button is clicked, it
> will replace the items making the old one collectable by the GC.
> If the Menu was never used/drop down shown, it will get collected.
> If it was used (just shown), it remains in memory (seen on VisualVM).
>
> GC Root points to ContextMenuContent.MenuItemContainer
>
> @Override
> public void start(Stage primaryStage) {
> this.primaryStage = primaryStage;
> primaryStage.setTitle("Hello World!");
> Button btn = new Button("New Stage");
>
> Button btnRefresh = new Button("Refresh Menu");
>
> ButtonBar buttonBar = new ButtonBar();
> buttonBar.getButtons().addAll(menu, btnRefresh);
>
> btnRefresh.setOnAction(e -> {
> menu.getItems().setAll(getMenuItem());
> });
>
> Scene scene = new Scene(buttonBar);
> primaryStage.setScene(scene);
> primaryStage.show();
> menu.getItems().add(getMenuItem());
> }
>
> private MenuItem getMenuItem() {
> MenuItem item = new MenuItem();
> item.setText("Menu Item");
> item.setOnAction(a -> {
> System.out.println("ACTION");
> });
>
> return item;
> }
>
>
>
> Em sáb., 20 de abr. de 2024 às 05:01, John Hendrikx <
> john.hendr...@gmail.com> escreveu:
>
>> I think this code is bug free, and the added fix shouldn't be needed --
>> the old MenuItems should be cleaned up, and so should the referenced Stages.
>>
>> So I think the bug is elsewhere, maybe not even in your code at all. I
>> did see PR's dealing with how MenuItems are linked to their platform
>> specific counterparts and how that can be a bit messy. I'm starting to
>> suspect maybe the MenuItems themselves are somehow still referenced
>> (perhaps only when they've been displayed once). These should also be
>> GC'd. They are however much smaller, so as long as they don't reference a
>> Stage it is probably not noticeable memory wise.
>>
>> An inspection with VisualVM should give an answer (or you could make a
>> MenuItem very large by attaching some huge objects to it that are not
>> referenced elsewhere, via its properties map for example).
>>
>> --John
>> On 19/04/2024 14:47, Thiago Milczarek Sayão wrote:
>>
>> When the window list changes, I'm calling item.setOnAction(null) on the
>> "old list" before inserting a new one.
>> In general it's not a problem because the menu item or button is in a
>> "context", like a Stage and everything is freed when the stage is closed.
>> Maybe on long lasting stages.
>>
>> The code goes like this:
>>
>> Window.getWindows().addListener((ListChangeListener) change
>> -> updateWindowList());
>>
>>
>> private void updateWindowList() {
>> Window[] windows = Window.getWindows().toArray(new Window[] {});
>>
>> List items = new ArrayList<>();
>> for (Window window : windows) {
>> if (window instanceof Stage stage && stage != primaryStage) {
>> MenuItem item = new MenuItem();
>> item.setText(stage.getTitle());
>> item.setOnAction(a -> stage.toFront());
>> item.setGraphic(new FontIcon());
>> items.add(item);
>> }
>> }
>>
>> for (MenuItem item : btnWindows.getItems()) {
>> item.setOnAction(null);
>> }
>>
>> btnWindows.getItems().setAll(items);
>> }
>>
>>
>> Maybe there's a bug, because the old list of items is collectable.
>>
>>
>>
>> Em sex., 19 de abr. de 2024 às 01:37, John Hendrikx <
>> john.hendr...@gmail.com> escreveu:
>>
>>> This probably is a common mistake, however the Weak wrapper is also easy
>>> to use wrongly. You can't just wrap it like you are doing in your example,
>>> because this is how the references look:
>>>
>>> menuItem ---> WeakEventHandler ---weakly---> Lambda
>>>
>>> In effect, the Lambda is weakly referenced, and is the only reference,
>>> so it can be cleaned up immediately (or whenever the GC decides to run) and
>>> your menu item will stop working at a random time in the future. The
>>> WeakEventHandler will remain, but only as a stub (and gets cleaned up when
>>> the listener list gets manipulated again at a later stage).
>>>
>>> The normal way to use a Weak wrapper is to put a reference to the
>>> wrapped part in a private field, which in your case would not solve the
>>> problem.
>>>
>>> I'm assuming however that you are also removing the menu item from the
>>> Open Windows list. This menu item should be cleaned up fully, and so the
>>> reference to the Stage should also disappear. I'm wondering why that isn't
>>> h
Re: RFR: 8146918: ConcurrentModificationException in MediaPlayer
On Thu, 22 Feb 2024 17:16:42 GMT, n-gabe wrote: > There is a ConcurrentModificationException in MediaPlayer when removing a > MediaView from it. The root cause is that you can't iterate over a HashSet > with for (WeakReference vref : viewRefs) and removing items from > the collection by viewRefs.remove(vref); within this loop. Sure, done. - PR Comment: https://git.openjdk.org/jfx/pull/1377#issuecomment-2068067764
Re: RFR: 8146918: ConcurrentModificationException in MediaPlayer [v2]
> There is a ConcurrentModificationException in MediaPlayer when removing a > MediaView from it. The root cause is that you can't iterate over a HashSet > with for (WeakReference vref : viewRefs) and removing items from > the collection by viewRefs.remove(vref); within this loop. n-gabe has updated the pull request incrementally with one additional commit since the last revision: Update Copyright - Changes: - all: https://git.openjdk.org/jfx/pull/1377/files - new: https://git.openjdk.org/jfx/pull/1377/files/857218e8..bdc1af6e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1377&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1377&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1377.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1377/head:pull/1377 PR: https://git.openjdk.org/jfx/pull/1377
