Discussion: Approaches to scene2d Layout/Widget measuring

This would probably be a better fit for a forum, but this place seems to be a better fit to reach other contributors

After seeing cae2342f08a368d15bed2d8d923f4f79f903d6f1 and fighting with similar issues myself:

How about we added Android-style onMeasure() instead of getMin/Pref/MaxSize?

• Working with wrapped Labels without it is a pain (and probably with some other widgets as well),
• it clearly defines when should a widget measure itself
• and generally, from my experience, it is more predictable to use.

I don’t like many Android constructs, but this one is IMO pretty good. iOS seems to be doing something similar, under the hood of Autolayout.

It would be a breaking change, but it shouldn’t be hard to write some temporary bridges to ease the transition. I know that there are some big applications written in scene2d.ui, so the costs of rewriting could prevent this from happening (maybe libGDX 2.0). But even if that would be the case, I’d like to know what the general opinion is about these two approaches.

Of course this is just about the general idea, it probably wouldn’t have the exact Android API. I’d volunteer to write the PR for this, given enough positive feedback. Implementation details could be further discussed there.

[NathanSweet]

Looking forward to seeing your prototype! 😄

An animation system is maybe tougher than it appears. Sometimes animations can be combined, other times they need to be cancelled, other times they need to be fast forwarded to the end. I have a feeling the most flexible solution is some sort of animation controller that handles just one type of animation, then application code can define what happens as the user takes more actions.

Using HarfBuzz for shaping would be awesome. We don’t have RTL support, but we already have on-the-fly glyph generation, enabling typing in CJK or most other LTR languages, even when the glyphs typed are not known beforehand.

[Darkyenus]

Ah, it didn’t occur to me to look into the getGlyphLayout(), so I guess that solves that.

I like the simplicity of current system (and the awesomesauce of Table). The only problem is, that some parts are not very intuitive (Label wrap) and sometimes slightly confusing (Group moving children around during drawing), but thanks to the overall simplicity, it is usually not hard to just write some code and do whatever.

I still feel that it could be possible to iron out some of these unexpected behaviors I’ve been struggling with, but I can’t really argue about replacing the proven system with something experimental and untested. So this discussion will be probably meaningful only after coming up and testing the proposed solution 😄

Wow, that Gloomhaven app looks really polished. And the animate functions are also pretty cool.

I agree with what you are saying about animations - making sure that they all play nice together, when user keeps tapping, resizing screen, etc. is really tricky. Some time ago I was (over)thinking about a solution, and I came up with idea to make a system which would track two scene-graphs: first immediate, in which logical state of the application would be kept, with all hierarchy changes applied immediately, and second that would be shown to the user and some manager would continuously animate the shown scene to match the logical one. Input events would be disabled on elements that are currently being animated, or could be applied immediately to the logical scene. I never got the time to actually implement it, but I think that there is some potential for some wild animations/transitions in this system.

Another idea is to put all changes to the scene, animated or not, into a queue, with an overseer, that would make sure that some animations/changes start only after there are no other animations to the same elements in hierarchy, possibly merging some changes in the process (merge running “show overlay” animation with “hide overlay” so that it looks like the showing stopped mid-way and seamlessly turned into hiding). The queue manager/applier would probably also have to maintain the state before current animation started, to correctly handle things like screen rotation or resizing, though that could be cheated by fast-forwarding currently running animation, then allowing the screen to rotate and then launching next animation in queue, if any. Input events could use the same mutual exclusion system used on animations, discarding those events that would affect currently animated elements.

Both approaches are, compared to yours, pretty general, but also much more complicated, so I am not sure if it would be possible to reach the easily debuggable levels of complexity, which scene2d.ui currently has.

I’d like to experiment with this as soon as I got some time. Another thing to try would be dynamic FreeType font generation, possibly with HarfBuzz layout, so that libGDX can support any language out of the box.