Show Posts
1
Window / Vertical wobbling while resizing a window in a multithreaded environment
« on: August 11, 2014, 03:05:30 pm »
Hello!
Lately I was implementing a SFML widget in Qt and experimenting with multithreading. I ran into a problem that causes SFML widget contents (ie. everything that's drawn on it) to wobble up and down when its height is being resized. The same doesn't happen when it's the width that is being changed.
What my code does is:
- create main window Qt widget,
- create SFML widget (doesn't do any polling, updating or drawing on its own, just deactivates the context upon initialization) on the main thread,
- create worker object on the main thread and pass it the SFML widget pointer,
- move worker to a separate thread and run its poll-update-draw loop.
Resizing happens on the main thread since the main window is passing the resized event to the SFML widget. I am using a sf::View to expand the viewport instead of resizing the contents. That's the code I use each time a sf::Event::Resized is polled. I tried doing this on the main thread and on the worker thread - no difference.
I discovered that if I move just the event polling and updates to a different thread and leave the drawing on the main thread the wobbling stops. I am trying to understand the reason of the wobbling but I'm not sure. Maybe it has to do with OpenGL having the coordinate system beginning in the bottom-left corner? What could be the reason and how could I prevent it while still having the drawing on a separate thread along with event polling and updates?
Minimal code spans across multiple files and requires Qt but I can upload it if needed. For the time being here's a video of what's happening. The wobbling starts when I change the height of the window in 0:24.
I am using stable SFML 2.1 from the main page and Qt 5.2.0. My operating system is Windows 7 Ultimate x64.
P.S. Event polling somehow works fine on a thread that doesn't own the SFML window, even though here it says it shouldn't. And it actually doesn't in a clean SFML application, so it's likely due to Qt.
Lately I was implementing a SFML widget in Qt and experimenting with multithreading. I ran into a problem that causes SFML widget contents (ie. everything that's drawn on it) to wobble up and down when its height is being resized. The same doesn't happen when it's the width that is being changed.
What my code does is:
- create main window Qt widget,
- create SFML widget (doesn't do any polling, updating or drawing on its own, just deactivates the context upon initialization) on the main thread,
- create worker object on the main thread and pass it the SFML widget pointer,
- move worker to a separate thread and run its poll-update-draw loop.
Resizing happens on the main thread since the main window is passing the resized event to the SFML widget. I am using a sf::View to expand the viewport instead of resizing the contents. That's the code I use each time a sf::Event::Resized is polled. I tried doing this on the main thread and on the worker thread - no difference.
Code: [Select]
m_view->setSize(width, height);
m_view->setCenter(width / 2.0f, height / 2.0f);
m_canvas->setView(*m_view);
I discovered that if I move just the event polling and updates to a different thread and leave the drawing on the main thread the wobbling stops. I am trying to understand the reason of the wobbling but I'm not sure. Maybe it has to do with OpenGL having the coordinate system beginning in the bottom-left corner? What could be the reason and how could I prevent it while still having the drawing on a separate thread along with event polling and updates?
Minimal code spans across multiple files and requires Qt but I can upload it if needed. For the time being here's a video of what's happening. The wobbling starts when I change the height of the window in 0:24.
I am using stable SFML 2.1 from the main page and Qt 5.2.0. My operating system is Windows 7 Ultimate x64.
P.S. Event polling somehow works fine on a thread that doesn't own the SFML window, even though here it says it shouldn't. And it actually doesn't in a clean SFML application, so it's likely due to Qt.