Hi,
Following the guidelines of the Issues page (http://www.sfml-dev.org/issues.php), I'm creating a quick forum thread for this (and I'll likely be posting a couple others over the next couple of days, hence why this text is quoted).
Do we even need the Window::m_size member variable? It's currently only an optimization. And if we can't rely on it being up-to-date and have to query the PImpl anyway, then it's useless.
It appears that calling Window::getSize() will always return m_size, even when the window is instantiated as a child of another window (by passing a handle in the constructor, for instance). This bug [...]I'm sorry if I missed something, but... I can't find any description of a bug in this discussion. What's wrong? Why is it a "bug" that Window::getSize() returns m_size? The implementation is supposed to make this work correctly, even when sf::Window wraps a native window.
Do we even need the Window::m_size member variable? It's currently only an optimization. And if we can't rely on it being up-to-date and have to query the PImpl anyway, then it's useless.The size not being up-to-date could be part of the issue at hand here, hence why requesting the size from m_impl seems to be fixing the problem.
I'm sorry if I missed something, but... I can't find any description of a bug in this discussion. What's wrong? Why is it a "bug" that Window::getSize() returns m_size? The implementation is supposed to make this work correctly, even when sf::Window wraps a native window.I suppose it wouldn't be considered a "bug" per-say, but what exactly would you call it otherwise? An oversight? An error?
@Theshooter7 while I am thinking about it, are you sure you are still polling the SFML window events when embedded in another window? I remember there being a few issues that would happen if SFML's events were not polled.Indeed I do not, as I delegated all events to wxWidgets. Turns out you're actually right! At least, glancing over the SFML source, it looks like m_size gets cached when filterEvent() is called from within pollEvent()/waitEvent().
Thank you for pointing this out. Perhaps a small change to the Documentation could be made to mention this for anyone in the future? Since no tutorial or otherwise mentions at this point that the event queue of a window must be processed in order for m_size to stay correct (and m_size is the only value that seems to be subject to this as well)It's an internal detail and nothing that should be documented. Maybe the tutorial could point out even more that processing events is a must. Even though we already have this red box in the tutorials:
A mistake that people often make is to forget the event loop, simply because they don't yet care about handling events (they use real-time inputs instead). Without an event loop, the window will become unresponsive. It is important to note that the event loop has two roles: in addition to providing events to the user, it gives the window a chance to process its internal events too, which is required so that it can react to move or resize user actions.
It's an internal detail and nothing that should be documented. Maybe the tutorial could point out even more that processing events is a must. Even though we already have this red box in the tutorials:Fair enough. I looked through the Events Explained tutorial and didn't see it; did not realize it was in Opening and Managing a Window.Quote from: Tutorial (http://www.sfml-dev.org/tutorials/2.3/window-window.php#bringing-the-window-to-life)A mistake that people often make is to forget the event loop, simply because they don't yet care about handling events (they use real-time inputs instead). Without an event loop, the window will become unresponsive. It is important to note that the event loop has two roles: in addition to providing events to the user, it gives the window a chance to process its internal events too, which is required so that it can react to move or resize user actions.
When I obtained the RenderWindow's size to use in an sf::View, it would return incorrect resultsAfter 7 posts of searching an irrelevant solution, we finally have a description of the problem ;)
You see now why I asked this: I know how sf::Window works internally, and I knew it was supposed to report the correct size if you had an event loop ; and I would probably have directed you to the solution if you had described your problem in the first post, instead of focusing on what you thought had to be fixed.You're right and I probably should have made it a bit more clear from the start. Sorry about that. :/