New demo release 11.13.2

[palexdev]

Changelog

A little side note on this new version
As you can see in the README, the build fails
This happens only on Windows (I can build MaterialFX with no issues on Linux and I believe Mac too) because of this: openjfx/javafx-gradle-plugin#120
The issue will be fixed as soon as a new release of the plugin is released

---

This discussion was created from the release New demo release 11.13.2.

[megabyte6]

I don't really care for the look of default JavaFX so I've been looking for a UI framework to improve the UI. I love the look of MaterialFX as well as how well-documented it is and am currently trying to decide whether to use it over JMetro or not. The only thing I'm a bit concerned with is the performance of MaterialFX. I've been playing with the current demo (version 11.13.5) and I've noticed that it's a bit slow on startup. But more significantly, there is quite a pause that occurs when clicking on different tabs.

The odd thing is that when running the demo app using .gradlew :demo:run, it seems to be completely fluid (after the first time I clicked it. Probably cause it needs to load the resources the first time). I find this really weird since the complied app with the executable seems to be much slower at loading resources.

The system I ran this on:

• 10th gen Intel Core i3 (3.59 GHz base speed)
• 12GB ram
• Timetec MS09 SSD

Would this be a concern if I made an app with MaterialFX?

[palexdev]

First of all thanks for your interest in the project, yeah the default look of JavaFX...quite frankly is garbage

Custom components/themes/libraries all of them have a certain impact on performance compared to 'original' JavaFX
However it is so low it should be unnoticeable, so don't worry too much about performance.
Also modern systems are more than capable and fast enough, especially with dGPUs

Your finding though is really interesting. The slow startup is normal, I coded the demo so that it loads and caches all the tab views at the start, so that then switching is smoother. The expected performance is the one in the second gif, the compiled demo.
I don't know why the packaged app is misbehaving that way, I'll try to investigate the issue, I hope I will be able to reproduce it though

[megabyte6]

Ah I see. What if the computer uses integrated graphics?

Oh, my apologies, I wasn't very clear about what the gifs were of. The first one is the compiled version. The second one is the one run with gradle.

[palexdev]

For iGPUs the performance is a bit worse in general but it should be more than decent anyway
Also, it shouldn't affect this case, since most of the computations are done on the CPU

I see, so the packaged app runs better than the compiled one, still very strange
Can you try package the demo too with jlink and check how it runs?

[megabyte6]

Alright, thanks.

I tried running the .bat from the link build but it doesn't seem to make a difference. For example, switching from the Buttons tab to the Dialogs tab is pretty much instant but switching to the ComboBoxes or the Lists tab could take from 500ms to 2s.

[stefanofornari]

just a thought: have you checked gradle uses the same java version as when you run it standalone?

[megabyte6]

Good point. I hadn't thought of that.
The compiled version runs on Azul Zulu 17.0.2
And running it on Gradle uses my local installation of Eclipse Adoptium 17.0.6.10

[megabyte6]

I ran the compiled version on Eclipse Adoptium 17.0.6.10 and the issue still persists.