Changes in RenderTextures/Texts?

[wintertime]

I just recompiled SFML from the git master version to continue on a GUI library I was writing a few months ago. I had made several versions of an example program for checking if everything looks correctly.
When I recompiled them with the new SFML version some new problems appeared:
1. One version of the program draws sf::Text strings on a sf::RenderTexture and later assembles some screens from them by drawing them onto a sf::Window using only OpenGL, but the text appears smaller now and on one part are some garbage pixels in same color as the text included.
2. Next version draws directly on a sf::RenderWindow using only SFML graphics. And this looks flawlessly, exactly like before.
3. Third version is like the second, but draws on a single screen-sized sf::RenderTexture and then draws that onto a sf::RenderWindow at once, but this appears mirrored along the horizontal axis.

I just want to know, have there been changes to these SFML classes recently, which could cause this? IIRC the smaller text could be from some recent bugfix I read about? And the mirroring, was that a deliberate change, too?
The garbage pixels, I think, may be from a new size mismatch between the changed text size and the same sized RenderTexture.

PS: No code, cause I'll fix that myself if I get the info that its needed.

[eXpl0it3r]

There have been changes to the text rendering, but I don't it should affect the rendering that you've described. You can find all the changes in the commit history.

Just some general questions: Do you use multiple threads to draw things? Did you mix debug and release modes? Do you call display() on the render texture?

A minimal example would still be helpful, so we can test it and see if it's an issue in the code or if we can actually reproduce it.

[wintertime]

I investigated a bit further and compiled new SFML dlls from the 2.1 tag. Using these the problem with the mirroring is gone, so I can attribute that to some change in SFML. Though I have doubts if the old or the new version is correct, as I vaguely remember having to re-sort the vertices back then.

To answer your questions, there is surely no mixing of debug and release, debug version uses debug dlls and release version uses release dlls and both had the same problems. 2 and 3 are completely single threaded.
1 is nearly single threaded, just to circumvent some other problem, only when a new texture is needed, it launches a new sf::Thread and immediately waits for that thread, inside it just creates a String, Text, RenderTexture, does a clear, draw, display, copies the internal texture into a newly created one.
Somehow the clear does not clear the RenderTexture, which causes the garbage pixels in both SFML versions I tested when normally running the program. I confirmed this by running it in the debugger and seeing the garbage replaced with a green color (debug memory fill I guess) while still having the text in the parts of the RenderTexture that got drawn to. That also causes some problems in the 3rd version that I forgot to mention.
I think the reason I did not have these problems earlier is because back then I still had a newer ATI card that I replaced with some ancient NVidia card that was laying around here when its stopped working reliably. That card does not support GL_EXT_framebuffer_object and I think there lies the problem, maybe the fallback implementation is bugged (I'm still looking for the root cause, could be some activation issue; code will therefore have to wait for later).

And lastly the text size, I'll adjust somehow to the change.

[binary1248]

Minimal code example... if you are still considering this as abnormal behaviour (I really can't tell). Yes... stuff has changed, and unlike other libraries/companies, we don't like declaring broken stuff as features just so that we can get away with not fixing them. People shouldn't get too dependent on broken behaviour. I'd prefer they spend more time complaining on the forum so that it gets fixed faster .

[wintertime]

You seem to not have read the thread carefully enough?
TLDR:
- I wrote I'm capable and willing to do the work on finding the causes of the problems myself.
- I politely asked about background information with respect to recent changes (after having traversed the git history for file changes already) and I'd still like to know, for example, if the change to the mirroring is a new glitch or a bugfix as I did not find the commit.
- I put some effort in providing a timely answer, gave as much information as I had at that time, told I'm still working on it and promised the example code for later.

Meanwhile, using the debugger, I found where the root of the problem with showing uninitialized memory and too small text lies. Its a mishandling of padded textures inside SFML that exists for a very long time already and that is mostly invisible, except under rare circumstances. I'll add an issue on the tracker when the test programs are ready.
Changes with the text rendering had only a very minor effect, which I already adapted to.

[binary1248]

You seem to not have read the thread carefully enough?

Maybe I read it too carefully, because what I take away from your previous 2 posts and this one is that things "seem to be different" but you don't know whether it is intended or not. Intended: fixed bug. Unintended: new/existing bug. If you know what is intended and what not, then you could discern whether to report what you consider a bug or not. I take bug reports seriously, but only if they provide non-conflicting information to work with.

If you are unsure of what is intended and what not, it doesn't hurt to write a small test program consisting of 100 or less lines and asking us what the intended output is. If we predict a result, but the code produces another, that is almost definitely a bug. That is also the easiest and most common way that SFML bugs are reported. It never hurts to just ask, it will save you and us a lot of time.

Yes... text rendering has changed, and for the better, because the old behaviour was filled with quirks that Laurent probably didn't intend to be there.

Meanwhile, using the debugger, I found where the root of the problem with showing uninitialized memory and too small text lies. Its a mishandling of padded textures inside SFML that exists for a very long time already and that is mostly invisible, except under rare circumstances. I'll add an issue on the tracker when the test programs are ready.

This is exactly what I mean. This is fixed behaviour. The previous implementation was adding too much padding, which it considered part of the glyph's size. Now glyphs are exactly the size you request them to be. If you request 30px, it will be 30px and not 32px as it was before. You should probably provide the code here for us to check out before opening up an issue on the tracker, since it is only for confirmed bugs. If the issue persists even in the new code base, or it turns out nobody else can reproduce the issue, then it is probably something not specific to SFML, i.e. driver related etc.

I wrote I'm capable and willing to do the work on finding the causes of the problems myself.

If you help us understand what exactly the problem is (again... minimal example), then maybe we can help you find out what the problem is? You don't have to do everything yourself you know... We are even happier to help you if it turns out it is really a bug.

I politely asked

And I politely answered . If you didn't see it that way, then apologies. I might come over as a very direct person at times.

background information with respect to recent changes (after having traversed the git history for file changes already) and I'd still like to know, for example, if the change to the mirroring is a new glitch or a bugfix as I did not find the commit.

You should check the file logs or use git blame for that... Sometimes, changes in one place might have non-trivial effects in others. The effects that a certain change can have might not be explicitly noted in the commit messages, so looking for a textual match doesn't always work.

I put some effort in providing a timely answer, gave as much information as I had at that time, told I'm still working on it and promised the example code for later.

We don't want to rush you . I just find it... a bit redundant to have to state here what you are currently working on. The best kinds of threads are those where there is a clear question/statement that can be answered without requiring too much feedback. It is great that you are reporting bugs, and trying to come up with a minimal example, but until you do that, you don't have to list every single step along the way. When people like me come by this thread, we get confused as to whether you are really requesting help or just stating the state of things. I prefer it if people keep those separate.

Changes with the text rendering had only a very minor effect, which I already adapted to.

This is unfortunately, again conflicting information. If you stated that the text was too small, you imply that the rendering is bugged. And yet in this sentence, you make it sound like you accept the fact that it is bugged and adapted to it ? You shouldn't have to adapt to bugged stuff. Report it and demand that it gets fixed. If nobody did this, when we finally fix it one day, everybody would be surprised again.

I don't mean to come over as offensive, but for every additional question that has to be asked in a thread, time is wasted. If you don't intend for people to try and help you yet, then try to state this in your original post so that I can come back to it at a later point. Who knows... there might be some who are already hard at work trying to reproduce what you briefly described. If it turns out that it wasn't an issue after all, all of their time would have been wasted as well.

[wintertime]

Excuse me, but misread again, the bug is in padded textures and is not from a new change (git blame/log/diff on these didn't help) and is not in the text rendering.
To clarify it a bit more, when textures are created they are allocated with power of two size if needed (GL_ARB_texture_non_power_of_two not available), but the texture coordinates/matrix are subtly mishandled in bind method in that case and then its made look worse cause the padding is (at least in some cases) not initialized.