SFML community forums
Help => Window => Topic started by: walru on May 22, 2023, 03:36:28 pm
-
Please bear with me, this is my first post.
I have been having issues with how slow my window polls events. My could main function is as follows:
#include <iostream>
2
3 #include <SFML/Graphics.hpp>
4
5
6 int main(){
7 sf::ContextSettings settings;
8 settings.depthBits = 24;
9 settings.stencilBits = 8;
10 settings.antialiasingLevel = 4;
11 settings.majorVersion = 4;
12 settings.minorVersion = 6;
13
14 sf::RenderWindow window(sf::VideoMode(200, 200), "SFML works!", sf::Style::Default, settings);
15 sf::CircleShape shape(100.f);
16 shape.setFillColor(sf::Color::Green);
17
18 std::cout<<"OpenGL version: "<<settings.majorVersion<<"."<<settings.minorVersion<<std::endl;
19
20 while(window.isOpen()){
21 ¦ sf::Event event;
22 ¦ while(window.pollEvent(event)){
23 ¦ ¦ switch(event.type){
24 ¦ ¦ ¦ case sf::Event::Closed:
25 ¦ ¦ ¦ ¦ window.close();
26 ¦ ¦ ¦ ¦ break;
27 ¦ ¦ ¦ case sf::Event::KeyPressed:
28 ¦ ¦ ¦ ¦ if(event.key.code==sf::Keyboard::Escape){
29 ¦ ¦ ¦ ¦ ¦ window.close();
30 ¦ ¦ ¦ ¦ ¦ std::cout<<"closing window: Esc pressed\n";
31 ¦ ¦ ¦ ¦ }
32 ¦ ¦ ¦ ¦ break;
33 ¦ ¦ ¦ default:
34 ¦ ¦ ¦ ¦ break;
35 ¦ ¦ }
36 ¦ ¦
37 ¦ }
38 ¦ window.clear();
39 ¦ window.draw(shape);
40 ¦ window.display();
41 }
42 return 0;
43 }
It seems to take a while to read the event type (usually I press the ```esc``` key just to close the window). When I comment out lines 39 and 40, the event is read rather quickly and closes the window. If they are commented out, it seems to take a rather large time (>10s) before it seems to recognize that the window should be closed.
I run on windows 10 using wsl2 from the Ubuntu 20.04 LTS environment. Is it possible the issue is related to WSL2?
In the terminal, I see the following output:
Warning: The created OpenGL context does not fully meet the settings that were requested
Requested: version = 4.6 ; depth bits = 24 ; stencil bits = 8 ; AA level = 4 ; core = false ; debug = false ; sRGB = false
Created: version = 0.0 ; depth bits = 24 ; stencil bits = 8 ; AA level = 0 ; core = false ; debug = false ; sRGB = false
Setting vertical sync not supported
sfml-graphics requires support for OpenGL 1.1 or greater
Ensure that hardware acceleration is enabled if available
OpenGL version: 4.6
I am not sure if it is related to the current problem or not but thought it might be helpful to include as well. I have an Intel(R) i7-6700HQ CPU and NVIDIA GeForce GTX 1060.
-
Did you install the vGPU driver, as described here: https://learn.microsoft.com/en-us/windows/wsl/tutorials/gui-apps
Are you even using the vGPU to display the GUI application?
The messages indicate that you're not having anything go to the GPU, which then falls back to really slow software rendering.
-
I am using X11 VcXsrv to produce the gui window. I am not sure if vGPU driver is installed (Set up the VcXsrv a while ago). I would guess its not installed for either my intel cpu or nvidia gpu's graphics setups.
-
I did this some time ago (https://duerrenberger.dev/blog/2022/06/18/code-and-run-apps-with-wsl2/) as well, but haven't really notice any slow downs. As said, it seems like your rendering isn't hardware accelerated, so make sure you enable that.
I think one of the crucial options was to change the XLaunch option to use native OpenGL
Personally, I recommend updating to the supported Windows 10 version and use the official vGPU drivers and not VcXsrv.
-
Thanks, I managed to get the hardware acceleration to work now (still with vcxsrv, too afraid to mess with my setup for ROOT browser). It runs at a reasonable speed now. I do however get a
Segmentation fault
when exiting the window but I don't think that is currently an issue to worry about.
-
At a guess, the segfault might be because your event loop closes the window (on escape or close button), but then does a clear, draw and display of the window (which is already closed).
-
Performing actions on an SFML window is fine, even after it is closed; they are just ignored.
It doesn't work so well when using an OpenGL (or OS) window directly, for example.
With that said, it can be a good practice to not ask the window to do things when you expect it to be closed.
One way to avoid this is to set a "running" flag and use that instead of "window.isOpen" and change that instead of closing the window. Then, when the loop is exited, close the window.
Another way is to put the event loop at the end instead of the beginning. This avoid the update and drawing sections after it is closed.