Hello again! 

I've got another bug, which was at first very annoying to try and figure out what caused it. It's easy to test though, so that's nice at least.

It would seem that the display / window re-sizes itself (or moves or something) when you set the re-sizable flag to true. It only happens if you enable it after the display has been created.
The bug causes some sort of movement and it also causes anything to not render in the right-most and the bottom-most few pixels as if the view port was messed up.

Also, in case I get a reply from spasi or Matzon, how's the 2.9.2 going?

Hey EnergyRay,

I have implemented a workaround for this issue. Could you please test the next nightly build? We should be ready for 2.9.2 after that.

I downloaded the nightly build and well... the workaround doesn't work all the time...

Now, if you set the resizability flag to true before you create the display, then disable and enable it again, you can see that the contents of the display move a little bit up and to the left, but it immediately corrects itself. If the flag is set to false before you create the display and then enable it, you get the same result except it doesn't correct itself unless you set the flag back to false.

Close, but no cigar!

If the flag is set to false before you create the display and then enable it, you get the same result except it doesn't correct itself unless you set the flag back to false.

Odd, this was the case I was working with. I tried some changes, please try the next build.

This is a shitty bug that makes no sense btw. Searching online I couldn't find anything like this issue. For similar issues the common suggestion seems to be "destroy and recreate the window", which I'd like to avoid.

Well, it's different now...

If the flag is off before creation and you set it on, the contents shift up and to the left (leaving white pixels at the opposite side).
If the flag is on before creation and then toggle it, the contents shift down and to the right... 

I can reproduce what you're describing, but only if I disable the workaround. I'm on Windows 8.1 though and I think you're on 7, so it could be that the workaround only works on my setup. Try this:

- Start with resizable = false.
- Set it to true. (client area moves to the upper-left).
- Manually resize the window slightly, just one pixel will do.

Does the client area snap back to the correct position?

Yes, I am indeed using Windows 7.

Manually re-sizing does in fact correct the position and if I remember correctly the earlier versions also behaved this way.

I have verified that this only affects AMD GPUs. Toggling resizable works fine on NV and Intel GPUs, though what's funny is that they both exhibit the shift + snap back behavior of my workaround. Since I can't find a reliable fix that works across Windows versions, I'll revert any changes I've made. Unless someone has a better idea or you're willing to work on it yourself to figure out a fix that works on Windows 7.

Well, thanks for at least trying... Unfortunately I don't really have enough knowledge regarding window systems and such, otherwise I might try to figure out something.

Also, is it possible to check if the user (and the user alone) re-sized the window? At the moment the wasResized() returns true if the window was re-sized or the display mode was changed. This makes it impossible to handle these two events separately. It's a minor "issue", as I have a workaround for it, but it did cause an interesting bug in my application (due to my own code ) which plunged it into a setDisplayMode()-spiral-of-doom. Oops!