Hi, I’ve noticed considerable slowdown when a Dialog is displayed. I’m using haxeui-openfl and build for html5 using openfl test html5. There’s a minimal test project here: https://www.dropbox.com/s/3yckyzr9oc0orfd/test.zip?dl=0
When you run this you should see a button and a simple tableview below it. Scrolling the vertical scrollbar of the tableview is relatively fast.
Now if you push the button it will open a dialog with another tableview and if you scroll this, it is much slower. Notice the tableview in the background below the dialog, now also scrolls much slower.
This issue might not be very obvious on a fast pc, but running on a basic mobile phone tends to show more than 1 second of lag before the gui responds to user input. I’ve seen it take more than 3 seconds. And that makes for a very unresponsive and frustrating user experience.
It’s not related to the tableview, I have multiple dialogs with checkboxes, buttons, textfields, and they’re all slow. I strongly suspect the dialog is the cause. Modal does not speed things up.
Any idea what could be causing this?
Or tips about where I should be looking?
I havent looked at the project yet, but my guess is its openfl filters - they are painfully slow. There isnt really much i can do about it.
However, there is a flag created specifically because of this openfl slowdown: haxeui_nofilters
If you define that then haxeui will ignore all filters (at the style level). Unfortunately i know a number of people who have had to use this until filters improve on openfl (which i think they are, slowly).
Also, if you want to just turn off filters for dialogs you can do something like:
.dialog {
filter: none;
}
hope that helps somewhat - and let me know if that is the issue.
Cheers,
Ian
EDIT: i just ran your application, and, although there is a slight slowdown, its barely noticable. I wonder if your version of openfl could use an update - first confirm that it is the filters though
EDIT2: OK, i ran it on html5 and the slowdown is more noticeable (though on my machine not by much)
EDIT3: last one! So, yeah, <haxedef name="haxeui_nofilters"/> “fixes” it in the sense than now the tableview is always nice a smooth - dialogs look a little crappy now though
Thank you for the very fast response!
This definitely helps. My actual app is based on an older version of haxeui and the “crappy” look could fit very well. I’ll go mess around with it. Thank you again
Numerous reasons, mostly bugs that I needed to circumvent quickly. So I hack in fixes everywhere that are not suitable for reintegration. It basically comes down to the reality of needing a working solution fast. Updates are always terrible for me because of this approach.
Hopefully I will one day have the time to update to the latest version and integrate everything nicely…
You may want to test on a bit slower mobile phones every once in a while. The visual bonus of filters under openfl is not worth the slowdown on these devices. These problems will of course go away in time, either by openfl optimizing filters or by users buying faster devices. But currently, for our customers, the visual bonus is not a real option.
Personally, though all the new components and visual flair is pretty awesome, I would prefer updates that focus on a stable fast bug-free code base. But I definitely get the need for a balance there.
