💿 Introducing Window Edit 2

Window Edit is a small Windows utility for managing, repositioning, and resizing application windows. The project is a rewrite of an older project of mine from 2018 that I called Window Edit (I am really good with names, I know.), so naturally, this project is Window Edit 2. I decided to rewrite it because I had a growing list of features that I had been wanting to add, but the old codebase was annoying to work in. I also wanted to try out new technologies for writing GUI applications in a more rapid way.

I originally created Window Edit to solve a very specific problem that had been annoying me for a long time: old games that don’t support borderless fullscreen mode. Some games let you resize the window in windowed mode, so you could maximize it, but that is not at all as immersive as true fullscreen! So, I created a tool that allowed me to force any application into borderless fullscreen. This app later grew to have more features like allowing you to mess around with any window’s properties directly, create position profiles, etc. - hence the name.

New application framework

For the rewrite, I decided to move away from using C# and WPF to C++ with Dear ImGui for the GUI. This might sound like a strange transition, but it actually made the project much easier and more fun to work on. The app naturally uses a lot of Windows API calls in order to manage windows. That is easier and clearer to do in C++. The decision to use an immediate mode GUI library made iterating the UI much faster for me, and it was very easy to add new features with almost no boilerplate code. I also like the look of it 🤓.

Even though Dear ImGui is designed for use in games, it actually worked surprisingly well for a standalone application like this. The only consequence was that I needed a game-like frame update loop to render my GUI. Since I make games for a living, this is a very natural way for me to work, and I know how to optimize it. You are probably wondering about resource utilization; it is actually very low if you set it up correctly. Simple optimizations like not updating/rendering unless something changes goes a long way, and rendering a simple gui like this doesn’t take a lot of time. The app uses only ~25MB of RAM on my machine (that is lower than what task manager uses), and shows up as 0% CPU while not focused, even though it is still updating regularly.

Why borderless fullscreen?

As I mentioned, the original reason that I created this program was to force games into borderless fullscreen. Why not just use exclusive fullscreen? As many people who have played older games know, exclusive fullscreen sucks. When an application enters fullscreen it has to take over the whole display from Windows, and maybe even change the display mode (resolution and refresh rate settings). It often takes a few seconds to go in and out of this mode. During this process, while Windows is struggling to resize everything and set the display back to normal, it is very hard to use the computer at all. The effect of this is that alt-tabbing between the game and other applications becomes slow and painful.

Back when exclusive fullscreen was still the norm, using windowed mode added a lot of latency and a significant performance penalty. This was because after the game was finished rendering the frame, it handed the rendered image over to the window manager, which then had to make a copy of the whole buffer and later composit it onto the desktop. These extra steps could have a significant impact on the game’s framerate.

Luckily, since then, Windows has added optimizations that allow games to use a much more efficient method for rendering games into a window. Now, games usually ask the window manager for a buffer representing the window directly, this is an internal buffer in the window manager that the game can render to, bypassing expensive copying steps. While the window manager still has to do compositing to be able to handle windows that are rendered on top of the game, it can now be done much more efficiently since it is responsible for the buffer. It can do a lot of smart optimizations that would not be possible otherwise, for example, if the game window is borderless fullscreen and set to render on top of all other windows, it may even be able to let the game draw right onto the screen via the provided buffer, bypassing the compositor! A side effect of not using exclusive fullscreen is that the application has to handle resolution scaling itself (since Windows decides which display resolution to use), but this is not really much of a downside, as it is straightforward to do, and most modern games want to do that anyway.

Thanks to these optimizations, the overhead of borderless fullscreen is now so small that there is no reason to use exclusive fullscreen anymore. Essentially, all games now secretly use a borderless window, even if the game just calls it “Fullscreen”.

Forcing borderless fullscreen

Now, it turns out that forcing a program window into a borderless fullscreen state is not that hard to do. You just have to update the window styles to remove the border of the window, then resize it to fit the display, and set it to render as topmost. This works for most games (and even apps), since they usually don’t update these settings while they are running. Because of how rendering into a window works, resolution scaling tends to work as you expect as well, even for games that do not have a user-resizable window. There are, however, some programs that do update their size or styles, and for these programs, the changes that Window Edit makes are reverted. But this is surprisingly rare in my experience.

It is important to note, however, that this way of forcing borderless fullscreen will not automatically make the game use all the optimizations that I described before, since they require engine-level support. So for older titles, you may see lower performance than in exclusive fullscreen mode. But, because we are talking about older games, this is often not a huge issue as they tend not to be as demanding as newer titles in the first place, and this is often a good tradeoff.

Getting hold of off-screen Windows

The “window editing” features also turned out to be quite useful. I use Windows a lot in my daily work, and sometimes the programs I use and Windows itself don’t always cooperate. Sometimes you may end up with a window that is stuck off-screen, or at least positioned in a way where you are not able to drag it back into position. While there are many ways of getting such windows back on screen, they don’t always work, depending on the application. This is also something that I wanted Window Edit to solve, and is the reason why it gives you explicit control over the position of all windows. I also added features that let you use Window Edit like a small window manager - you can double click on any window to focus it, and there is also a button to bring a program back to the center of your main display.

Download

You can check out the code and download the program on my GitHub.