RenderWindow's .setVerticalSyncEnabled() resets when .create() is called #371

santiaboy opened this Issue Mar 23, 2013 · 9 comments

9 participants


Making an options menu I realized .setVerticalSyncEnabled() resets when .create() is called.
I think this may be a bug, because for example setFramerateLimit doesnt reset at all
Below I provide small examples to show what I mean.

this is the code to show setFramerateLimit doesn't reset (to "unlimited" FPS) when create() is called

This is the code to show that setVerticalSyncEnabled does reset to false if create() is called

a simple fix is to set setVerticalSyncEnabled to true, every time you call .create(), like this:

app.create(VideoMode(800, 600, 32), "SFML Test");

Actually when you call the create function non of the previous settings are transferred over besides framerate limit. I don't think it's a bug but would defiantly be something worth mentioning in the documents.

The only setter function that doesn't get reset is setFramerateLimit.
The setSize, setTitle, setIcon, setVisible, setVerticalSyncEnabled, setMouseCursorVisible, setKeyRepeatEnabled, setJoystickThreshold, setActive all get reset because they are working directly with m_impl and m_context.

Simple and Fast Multimedia Library member



So, instead of simply stating in the documentation that these properties are reset, could they be saved and automatically reapplied after the window (re)creation?

And there's the setPosition property as well.
Saving position would be a useful feature, given the following scenario:

Let's say I want to center my window on the desktop when I create/recreate my render window, for which I need to place the window at a given position.

  • setting the window position doesn't work if applied before the window creation
  • if setPosition is called after, the window is already created, thus the window is visible at its default position for a fraction of seconds, which is not very nice to the eye

When I created the issue I though that the standard thing was that the settings were transferred, but I only tested with those two, bad :)

More on topic, maybe let the programmer decide? I don't know how difficult is this to code(or if you even want to implement something like this) but creating a funciton propertiesReset(bool) that is enabled to true by default, and if it is set to false all the setSize, setTitle, etc don't reset.


I'm willing to push a few commits for reapplying the settings.

I would simple save all settings into properties of the class and reapply on a create. If we do this then we should also have a reset method. The only cons of this is more memory usage and slightly more cpu.


What about just actually removing framerate limit on create() too? Principle of least surprise.. it's a fresh window, everything is reset, the effect would be similar to creating new sf::RenderWindow instance and throwing away the old - 'this is your window, it's in default state, do whatever you please', no wondering if this or that got cached or set to different value or whatnot. This is made into potential trap as it is now if someone turns on vsync on created window that had the limit before(ie switching to fullscreen and vsync from windowed with fps limit).


I have to agree. It would make a lot of sense, that if you create a new window the old properties are thrown away and you get the default ones.
But the way I see it, especially for game programming, 99% of the time .create() is used to switch between windowed mode and fullscreen (in the running app i.e. not at setup). Of course it's anoying if you then have to reset all the properties. I think for all other cases, if you .create() a window, you'd expect it to be new and set to the default properties.
So I'd say everything should stay as it is, but there should be a method that allows switching to fullscreen mode, without having to recreate the window (as far as I know there is already a method that does that in the implementation for sf::Window, it would just have to be exposed)


In my program it so happens that the main thing I have to manually reset after each create() call is my views, so that's (arguably) yet another set of window properties to consider here.

Would it even be possible to have a recreate()/changeMode()/whatever function that preserves views (which may involve automatically scaling the viewports) as well as all the obvious window properties?


I would totally love a way to change the video mode and toggle between fullscreen and windowed without recreating the entire thing.

@Bromeon Bromeon modified the milestone: 2.2, 2.x Mar 18, 2014
@Bromeon Bromeon assigned Bromeon and unassigned LaurentGomila Mar 18, 2014
@Bromeon Bromeon added the resolved label Apr 6, 2014
@Bromeon Bromeon closed this in 18bbd23 Apr 6, 2014
@MarioLiebisch MarioLiebisch added a commit to MarioLiebisch/SFML that referenced this issue Apr 15, 2014
@Bromeon Bromeon Window::create() now also resets framerate limit
Fixes #371
@jcowgill jcowgill added a commit to jcowgill/SFML that referenced this issue Sep 22, 2014
@Bromeon Bromeon Window::create() now also resets framerate limit
Fixes #371

(cherry picked from commit 18bbd23)
@Bromeon Bromeon was unassigned by santiaboy Apr 30, 2015
@eXpl0it3r eXpl0it3r pushed a commit to eXpl0it3r/SFML that referenced this issue Sep 10, 2015
@Bromeon Bromeon Window::create() now also resets framerate limit
Fixes #371
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment