UI layout system #1219
Replies: 3 comments 3 replies
-
Yeah I agree that the stretch performance problem needs to be solved for bevy_ui to be useful. Forking stretch does seem like a bit of an endeavor. Glad you're taking a look at this! On the topic of flexbox vs alternative layout: I think using flexbox wasn't the "user experience win" I thought it would be. Maybe we just don't have enough webdevs writing Bevy UI code, but enough people are regularly confused by it that I'm very open to considering alternatives. Anchors are the natural choice because so many other engines use them (and the web's absolute positioning system behaves similarly). We've already discussed this, but for everyone else: bevy used to use an anchor system prior to flexbox, which you can see here. I'm curious to see how yours differs! |
Beta Was this translation helpful? Give feedback.
-
Here is a PR that should fix the performance issue: vislyhq/stretch#81 On the topic of "user experience win", I believe it would be very different with even a basic editor. |
Beta Was this translation helpful? Give feedback.
-
I made roughly the same UI using both the current system and my newer one here. The old system currently hangs on startup because vislyhq/stretch#81 hasn't fixed all corner cases and still has a place where it falls to exponential recursion. I'll do serious benchmarking once both systems can run the layout at 60 FPS. In terms of usability of the 2 apis, mine feels overengineered and a bit verbose, but has less implicit priorities between various constraints. I'd love if someone would take a look at the api and provide feedback. |
Beta Was this translation helpful? Give feedback.
-
PRIOR DISCUSSION
Currently, stretch is a major bottleneck in terms of performance, and has been inactive for the last few months: last commit is May 22, and last comment is from June 29. This leaves us with three options:
Hope the maintainer comes back and fixes the major performance bottleneck.
Fork the project and fix it ourselves
Implement and switch an alternative layout system
There are issues with all three options: with option one, there is an insignificant chance the maintainer doesn't come back and fix the issue by the time major work begins on the UI system, forcing us to choose a different choice anyway.
With option two, we adopt a large codebase, and commit to supporting a large, messy, and complicated system. The algorithm is well documented, but still over 1000 SLOC.
With option three, we still have more code to maintain, but it can be leaner and easier to extend because we no longer need to adhere to a previously laid specification. This has the negative side effect of being less familiar to those with web developer backgrounds. Furthermore, this would be a very large change and create a large migration challenge.
I have done the implementing part of Option 3 here, largely as a proof of concept and I haven't benchmarked it against stretch yet. I will post these benchmarks as soon as I make them.
Beta Was this translation helpful? Give feedback.
All reactions