Label - set size

Started by netrick, 17 July 2013, 17:53:42

netrick

I think that editbox does it (and probably chatbox as well).

Label should allow to set its size and if the text doesn't fit inside it then the text will be cut (very important step to implement resizing). The same should apply to text on buttons etc.

What do you think?

Gui libs like QT etc implement this.

texus

This actually was the way label behaved earlier.
In SFML 2.0 (not the github version), getting the size of the window was slow on linux. My current clipping algorithm needs the size of the window (because glScissors starts from the left bottom corner of the screen which makes the calculations a bit harder). It was so bad that ChatBox (which made use of labels) couldn't have more than a few lines before getting serious performance issues. Because of this, setting the size and clipping in label were removed.

So I would prefer to wait until SFML 2.1 is released before reïmplementing this in label.

And for widgets like button, I think you are responsible for setting a text size that fits inside it (or set text size to 0 to auto-scale).

netrick

#2
SFML 2.1 may as well be released in 2015. I see 2 solutions here:

1) Encourage people to use github version (okay, this may be hard when someone want to redistribute game with stable SFML package) so it's bad for most ppl unless someone like me provides his own libs with game on linux and uses rpath.

2) Cache window size during resize event in tgui. It requires a bit of work though.

EDIT:

3) Use other algorithm that works only on text's texture and ignores window size ^^

texus

#3
I was actually working on solution 2 when the fix was made in sfml. But I'm not going to continue it (or better said restart, because I didn't keep the code).

SFML 2.1 should be released relatively fast though, its only a bug fix release.
I just checked and there are only 4 more open bugs marked for 2.1. A lot of bugs were closed in the last few weeks, so I'm going to stay optimistic.

Edit:
3) There isn't really an alternative.
I'm waiting for issue #1 to be closed so that I don't have to use opengl myself to clip. But that is something that might indeed not happen before 2015.

netrick

#4
I understand. 0.6 is a development release so I think that you can safely reimplement label clipping (anyone wanting production quality should use stable version anyway). SFML 2.1 may be released in few months and it will probably happen before tgui 0.6 goes stable.

However, you can do it when you want. I will just wait.

texus

The other reason why I don't want to implement clipping again (except for the fact that it slightly is slower, even with the changes in SFML 2.1), is that I am not sure if clipping is the correct way.

You could also make the label fit inside the given size.
So it is either cut of the parts that fall outside the box, or make the label fit inside the box.

I haven't really decided on that either, although clipping is probably the best option.

netrick

How are you now making sure that text in chat box fits inside it?

texus

If the line is to long it will be split over multiple lines. No clipping needed there.

netrick

#8
I think I have a solution for label without clipping!
Basically inside label there are 2 strings - full text and displayed text. If full text doesn't fit inside the label, then the displayed text string is cut and converted to sf::Text. Of course it's not the fastest operation but it only happens when you setSize to label (so only when you resize/create the window).

What do you think? The same should be applied to button.

I think it's great and clean solution.

I'm pushing for it because I want to have TGUI automatic resizing up and running as soon as possible as I'm getting closer to pre-alpha release of my game and gui layout is basically the only big thing left.

texus

I'd still prefer normal clipping over that. This is just a different form of clipping (faster at draw time but slower when calling setSize).

But whatever method I use (probably just clip like it was before), I need to make a decision about what should happen when changing the text after setting a size. When not setting a specific size then the size should be changed automatically to fit the text, while if you have set a size then the size should stay the same. So I'll add an autoSize method again.

QuoteI'm pushing for it because I want to have TGUI automatic resizing up and running as soon as possible as I'm getting closer to pre-alpha release of my game and gui layout is basically the only big thing left.
I'll do my best to help with what you need, but I doubt I could get a very good layout system in v0.6.

By the way, how is clipping label going to help with what you need?


netrick

#10
Quote from: texus on 17 July 2013, 21:36:18
I'd still prefer normal clipping over that. This is just a different form of clipping (faster at draw time but slower when calling setSize).
Keep in mind that you draw 60 times a second and you setSize basically only when initializing app or resizing it. Also operating on sf::Text isn't that slow.

Quote
I'll do my best to help with what you need, but I doubt I could get a very good layout system in v0.6.
I know that layout system is so hard to design that you won't make it quickly. I mean the semi automatic pseudo-layouting on which I'm working right now. That's what's enough for me. The change in tgui::Transformable was enough to make it happen. Now only text clipping issue is left.

Quote
By the way, how is clipping label going to help with what you need?
For example when resizing using my method the labels' size is reduced, I don't want the text to be messed up (eg outside of the layout) but I want the text size to be actually reduced. The same applies to button of course.

If you don't want to implement any of the 2 forms of clipping at this stage, then auto font size with option to set maximum size could work as a workaround for a few months.

texus

For single line labels your clipping solution will indeed be better, but I'm more worried about when you have multiple lines. I would have to find out how many lines need to be visible and that is an even slower process. Of course it will probably still be faster than clipping every frame, but I guess I'm just lazy and I know that implementing clipping when drawing is much easier to write.

Anyway, I'll implement clipping in the draw function again. Optimizations can come later.

So label should become like it was in v0.5 again. Read the documentation about setSize, setText and autoSize. Is this the design you need?

netrick

Yes, 0.5 labels are exactly what I need. Thank you that you will implement it :)

I think clipping optimization will come automatically with SFML 2.1 release (and we must agree that 90% of TGUI users/users of our games use Windows so no problem there on 2.0).

texus

Clipping was removed earlier because the fix wasn't in sfml yet. I agree that now the fix is already in the github version and because most people do use windows it isn't a problem to add it again.

The changes have just been pushed.

netrick