On Wed, 23 Apr 2025 09:46:06 GMT, Thiago Milczarek Sayao <tsa...@openjdk.org> wrote:
>> This is a continuation to >> [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to >> stabilize the linux glass gtk backend. >> >> >> Overall, it has been made more robust within its scope, particularly in >> terms of sizing, positioning, and state management. >> >> List of changes: >> 1. It embraces the asynchronous nature of X11 by reporting geometry changes >> only upon receiving a configure event, rather than immediately as before. >> This is because it merely requests changes from the window manager, which >> may or may not honor them. However, it still reports changes immediately in >> certain special cases, such as when the window has not yet been realized >> (i.e., when the window has not actually been created yet). One scenario >> where this behavior is evident is when we request the window to move to >> position (0, 0), but the window manager instead places it in the top-right >> corner where panels converge. >> 2. FullScreen now keeps track of geometry changes and apply them on restore >> as documented on Stage.java. No geometry changes affects the FullScreen >> state; >> 3. States (fullscreen, maximized and iconify) are now reported back to Java >> when it actually happens rather than immediately (except when not realized); >> 4. When a window is maximized, it will ignore geometry changes and restore >> to the geometry it had prior to being maximized. After some testing, I >> believe this is the best behavior for platform compatibility; >> 5. Unifies the WindowContext class: previously, there were three separate >> classes—two of which (for applets and Java Web Start) were removed, leaving >> only one. However, the supporting infrastructure was still there partially. >> [Unify WindowContext in >> glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768) >> 6. `setAlpha` and `setBackground` were removed because they no longer >> function correctly due to the lack of shared rendering. It's not possible to >> paint a background using GTK and then render custom content on top of it, >> unless the rendering is done by Gtk (it is not). It is possible to keep the >> background by painting with cairo, and make it work with software rendering, >> but that's a very remote scenario; >> 7. Tests were added and re-enabled to ensure everything works correctly. The >> stage tests now cover various StageStyle configurations, as I found that >> `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` >> stages; >> 8. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`; >> 9. It no longer keeps track of ge... > > Thiago Milczarek Sayao has updated the pull request incrementally with one > additional commit since the last revision: > > Reenable RestoreSceneSizeTest (JDK-8353556) I'll give this a thorough read and report back. In the meantime, I recently was tackling [JDK-8321624](https://bugs.openjdk.org/browse/JDK-8321624) and i have to wonder if it got fixed in the process of your changes? It is intermittent, I managed to get it to fail locally on my VM and it seemed like a race between window manager showing the window and us wanting to move it. Judging by the list of bugs you fixed this one could maybe also make he list. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-2826691355
