JFormDesigner
Improve on Window resizing
Hello,
I really like this Look and Feel!
One area, which might could be improved upon, is the resizing behavior of windows.
Let's first sum up the observations, that can be made:
- On Windows 10 the contents are only resized after ending the mouse movement
- On Ubuntu 24.04 the text appears to be jittering, while resizing
- On Ubuntu 24.04 the background in the "not painted yet" area does not match the theme color
- On Ubuntu 24.04 the whole area of the window seems to occasionally have a complete black frame
This leads to following questions:
- Is it possible/desirable to have the same resize behavior on all operating systems? Would that mean making it on Windows 10/11 more responsible? Or maybe fix the problems on Ubuntu by making it behave like it does on Windows?
- Can the resizing issues on Ubuntu be addressed by the Look and Feel? Or is the problem rooted in the JVM?
On Ubuntu the resizing has no "delay". While on Windows (10 at least) it seems, that the mouse needs to stop moving, before the contents inside will be resized.
Resizing on Windows: https://github.com/JFormDesigner/FlatLaf/assets/84087666/b6285d91-cc29-4f2d-9fed-ad59325478ea Note how the resizing takes place only after finishing the mouse movements.
Resizing on Ubuntu (FlatDark Theme) https://github.com/JFormDesigner/FlatLaf/assets/84087666/08bf7d54-337b-4a8d-b740-1d98ca2b4e4a
- The background in the "not yet painted" area, is white and sometimes black.
Resizing on Ubuntu (FlatLight Theme) https://github.com/JFormDesigner/FlatLaf/assets/84087666/bfa15a01-edcb-4aaa-8ad9-a501a2ea16d1 Note:
- The texts seem to jitter or change size, while resizing.
- The background in the "not yet painted" area, has another color, than the FlatLaf Theme, but in this case it seems to be neither black and white but the gray tone, which would be great for the FlatDark theme.
- Very rarely but still noticeable, the complete area of the window renders black for a frame.
Resizing on Ubuntu (Metal) https://github.com/JFormDesigner/FlatLaf/assets/84087666/1c071690-9a43-40c0-a3a3-28597e55913b I also looked at the resizing behavior with good old metal look, which is even more laggy. So maybe it is a combination of Java + Operating System which cannot be addressed by the Look and Feel?
This is a characteristic behavior of Swing, I have always observed this in Swing applications, from the most basic to the most complex layouts. Applications written with JavaFX, this does not happen, the graphical capabilities have been improved.
Do this same test on your videos with a JavaFX application and you will see that nothing like this happens. :+1:
Hello. On linux, this problem is partially solved by enabling hardware acceleration in the JVM:
java -Dsun.java2d.opengl=True -jar /home/flatlaf-demo-3.5.4.jar
I haven 't been able to find a solution on Windows yet ...
Hello. Thanks for the suggestion. I tried it out. Unfortunately on my ubuntu system it had the effect, that my desktop was hanging until a message showed up, that the X11 Server crashed, and took me back to the login screen. At the start it was working fine, I think the crash happened, when my Application was placing itself in the system tray. The swing system tray also seems to have problems on ubuntu - especially, with the opengl parameter apparently...
Kind of unfortunate, because I thought I would use flatlaf despite java fx being an alternative. flatlaf does offer some advantages, like styling the window title bars according to the theme out of the box.
I haven 't been able to find a solution on Windows yet ...
I think on Windows it is not as annoying, as the flickering on Linux. But that might just be personal preference.
Maybe this issue can not be addressed by flatlaf. Then I would need to hope for a newer java version to fix the flickering.
@CodingFuchs thanks for the report and the details.
The resize behavior is not controlled/implemented by FlatLaf. This is completely done by Swing.
On Windows, window resizing is fixed since FlatLaf 3.5.2,
which sets Java system property sun.java2d.d3d.onscreen to false (see issue #887).
On macOS, window resizing is super fast.
On Linux, I don't see your problems.
On Ubuntu 24.10 (Java 8 and 21; VirtualBox) it resizes smooth and fast. No text jittering or temporary black/white areas on resizsed edges. Also works fine on KDE neon.
https://github.com/user-attachments/assets/32669b9e-c370-4c07-8346-ffebc9063dc2
On older Ubuntu 22.04, sometimes the drop shadow seems not to follow fast enough when making a window smaller:
The behavior on your Ubuntu system is very strange. Seems that the window content (as bitmap) is temporary "zoomed" while resizing window.
Screenshot taken from your video. Left is before resizing. Right is during resizing.
Don't know why this happens on your Ubuntu. I can't see such a behavior here (on various Linux distros).
Do you have other Linux distros or other PCs? Do they show same behavior?
@DevCharly Thanks for you reply.
The behavior on your Ubuntu system is very strange. Seems that the window content (as bitmap) is temporary "zoomed" while resizing window.
Yes, that sound like an accurate description of what is happening.
I am not sure, if I am onto something: So your Ubuntu video was butter smooth and just to make sure that my problem is not because of the Ubuntu 24.04 release, I upgraded my main Computer to Ubuntu 24.10. I relaunched flatlaf and for the first launch it was super smooth. Then after relaunching one more time the problems were back.
I attached a video showing what I just described.
https://github.com/user-attachments/assets/25fcf0b6-5f9f-4084-ac69-b3e5ee5f2d03
Here is my theory: On the first launch, the startup look and feel was nimbus, which does not modify the System TitlePane appearance. Then switching over to DarkLaf, does not change the TitlePane and the resizing is perfect. Once I restart the whole Demo and it immediately starts up with darklaf set, it will modify the TitlePane and the problem appears.
So my suspicion would be that customizing the TitlePane has something to do with the problem. But it may just be a coincidence.
I am curious on your opinion on this discovery. Unfortunately I have no other linux distributions in my dual-boot setup. But the next Ubuntu release is not that far away.
Is there a way to keep the native window decorations, when initializing flatlaf on startup? That would help to prove or discard the theory.
Interesting that the behavior is different when using native window decorations 😕
Does the behavior (with FlatLaf decorations) change if you start with disabled OpenGL? E.g.:
java -Dsun.java2d.opengl=false -jar flatlaf-demo-3.5.4.jar
I don't think this is a problem in Ubuntu. Looks more like a Java issue...
What Java distro do you use?
What does java -version output?
Have you tried another Java version.
For testing, you could download any (latest) OpenJDK distro as .tar.gz (or .zip),
extract it and run the FlatLaf demo with it. No need to install it.
Is there a way to keep the native window decorations, when initializing flatlaf on startup?
Sure, do not enable it in your app 😉
Do not invoke JFrame.setDefaultLookAndFeelDecorated(true) and JDialog.setDefaultLookAndFeelDecorated(true).
I thought I would share some more feedback concerning this issue. All videos below have been recorded with Java 22, but I also tried it with the latest oracle jdk 23, which did not make a positive difference.
Video 1 - FlatLaf Demo but only Native Window Decorations:
https://github.com/user-attachments/assets/61eae450-aed0-4586-b61c-9bd5ddfe3862
With native window decorations, resizing is smooth. However, there still seems to be some pixel edge at the very border of the resizing area, which I cannot notice in your video. No idea, how your virtual machine manages to be even better at that. But this behavior can be ignored, because the overall result is still really good.
Video 2 - FlatLaf Demo without OpenGL:
https://github.com/user-attachments/assets/e4c5cc1e-d9da-4ab9-8069-73613e24fbb0
Turning off OpenGL is the worst resizing I have seen. You would not believe, that I have a RTX 3080 in my rig...
Video 3 - FlatLaf Demo with Decorated Windows:
https://github.com/user-attachments/assets/db2ce5a7-fbfc-45f8-9c8b-9d6cee70bab0
This video is for reference to compare it, with you latest changes concerning X11.
Video 4 - FlatLaf with your latest X11 Commit checked out:
https://github.com/user-attachments/assets/1bd7ddaf-9fe8-43a1-9379-7c8eb73d9928
With your latest commit, resizing seems more stable. The random frame flickers seem to be gone. But there still seems to be some lagging Bitmap Scaling going on. It seems like its painting the content to late, when the size does not match. I wonder, whether double-buffering has something to do with that? Having buffer content with a size, that does not match the size of the JFrame anymore, thus resulting in the effect we can see in the video.
That's all I got at the moment. I am interested, if you think tackling the bitmap resizing paint lag would be possible or not.
@CodingFuchs thanks for your feedback.
I was actually hoping that the latest X11 commit would fix the problem because now the window is resized by the WM in the same way as when the window has system decorations/borders. Strange that resizing decorated and undecorated window behaves different on your system.
On my system, in VirtualBox, I don't see such "bitmap scaling"... Don't know where this comes from. It also occurs with undecoraded windows in Metal L&F (see last video in first post).
I am interested, if you think tackling the bitmap resizing paint lag would be possible or not.
Don't know. I have no idea...