Jump to content


Photo

Why is Borderless Window recommended as a performance increase over Full-screen in the ENBoost guide?


  • Please log in to reply
6 replies to this topic

#1 Tyler799

Tyler799

    Prisoner

  • Members
  • 28 posts

Posted 10 September 2016 - 04:07 PM

In this ENBoost guide: http://wiki.step-project.com/ENBoost

 

It is said that swapping to Borderless Window: 

 

[WINDOW]
ForceBorderless=true
ForceBorderlessFullscreen=true
 
Will somehow reduce stuttering and increase performance. I don't understand how this is the case. As I've understood it, most games should benefit from being in full-screen, or be equal in performance in other conditions. 
 
The reasoning I heard being:
You will notice a slight performance increase while playing in full-screen if all of the following conditions are true:
  • Windows OS
  • Playing Skyrim at your screen's native resolution
  • Your desktop is also set to your screen's native resolution
Why?
 
"When an application runs in fullscreen mode, it runs in "exclusive mode". That means it has full and direct control over the screen output. But when it runs in windowed mode, it needs to send its output to the window manager (windows explorer) which then manages where on the screen that output is drawn. This takes some additional performance. The performance penalty, however, is greatly reduced in newer versions of windows."
 
If you plan on lowering your resolution to gain performance, then full-screen will not benefit you
 
Here is the reasoning:
 
"Fullscreen mode at non-native resolution means that instead of shifting graphics output to a rectangle on the screen (something relatively fast), your computer instead has to scale the picture from the game resolution to your native resolution with bicubic filtering or better (expensive!)."
 
This performance increase is apparently less noticeable in Window OS's past Vista, however, it should still be true for later versions. 
 
Anyone care to explain any of this? I'm just running off what other people have said on other forums. I admittedly don't understand it myself all that well. 

Edited by Tyler799, 10 September 2016 - 04:07 PM.

  • 0

#2 TechAngel85

TechAngel85

    Akatosh

  • Administrators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 11,858 posts

Posted 10 September 2016 - 09:36 PM

When comparing apples to apples the difference between the two on any modern system is not going to be measurable to the human perception unless you are some kind of superhuman. I'm a schooled and trained IT hardware/networking guy. This was a thing many years ago when our computers weren't as powerful. However, the recommendation to "try it if you have stuttering" is there because it has helped some users in the past.



#3 DoubleYou

DoubleYou

    Wiki Stepper

  • Super Moderators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 4,466 posts

Posted 11 September 2016 - 11:21 AM

Some people like it for alt-tab functionality.

#4 Tyler799

Tyler799

    Prisoner

  • Members
  • 28 posts

Posted 11 September 2016 - 12:02 PM

When comparing apples to apples the difference between the two on any modern system is not going to be measurable to the human perception unless you are some kind of superhuman. I'm a schooled and trained IT hardware/networking guy. This was a thing many years ago when our computers weren't as powerful. However, the recommendation to "try it if you have stuttering" is there because it has helped some users in the past.

In which direction though?

 

The main reason I'm asking is because the STEP guide suggests that borderless is advantageous, while what I quoted suggests the opposite.

 

I just want to know where the STEP guide got that information. 


Some people like it for alt-tab functionality.

And that's well and good, but that's not what the guide says. 

 

"This may be a necessary performance enhancement for some users." 

 

I want to know why they say that. Where did they get that information? Why does it conflict with what I've researched? 


  • 0

#5 TechAngel85

TechAngel85

    Akatosh

  • Administrators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 11,858 posts

Posted 11 September 2016 - 12:19 PM

It came from personal experience from users and staff. I don't have any references for you. If it bothers you to such a degree, ignore it. I already stated it's not an all-encompassing rule. For some it helps, for some it doesn't.

I already told you the information you provided from your research is not something relevant to modern systems. Feel free to try to prove otherwise.

#6 DoubleYou

DoubleYou

    Wiki Stepper

  • Super Moderators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 4,466 posts

Posted 13 September 2016 - 10:47 AM

I think it can affect vsync somehow as well iirc.

#7 generalmx

generalmx

    Citizen

  • Members
  • Pip
  • 59 posts

Posted 20 October 2016 - 02:31 AM

Playing any game in windowed mode forces Vsync enabled (unless somehow disabled at driver level) as Windows itself forces Vsync enabled for a smooth experience and windowed mode must ultimately render through Windows rather than directly presenting through DirectX--which allows direct access to hardware while in "exclusive" or "immediate" mode. Furthermore, you get all the benefits of newer versions of DirectX rather than just some of the benefits (for a DX9 game) as of course the Windows renderer uses the latest version of DirectX it supports. However, since the application no longer has direct control over graphical memory and rendering priority, Windows is free to assign that memory elsewhere whenever it feels like it, leading to problems if you're on a threshold where you're near running out of VRAM; what happens is that Windows can assign it elsewhere, THEN figure out "oh wait this game needs it", all too late leading to dropped frames. Windows is a generalized operating system, not designed for any one thing except general workstation and server usage, so when you let it take control it will have priorities you don't expect (process priority also affects this, which is why all Windows game systems, even high-end ones only running games in fullscreen, should use ProcessLasso; I've increased FPS by 10+ on taxxed systems compared to setting priority manually). On my current rig--I'm in-between high-end cards and using a GTX 560 Ti atm--Borderless Windowed on Windows 10 with Skyrim and FNV leads to much more instances of sub-60 performance than running it fullscreen.

 

I think what's confusing is that, AFAIK, Skyrim has one Vertical Sync variable called "iPresentInterval"--this being an integer makes me think it may be the one of the D3DPRESENT_INTERVAL_xxx D3D9 flags such as "1" == D3DPRESENT_INTERVAL_ONE--and disabling this causes all sorts of problems in scripting and elsewhere. This is probably because the game, being essentially single-threaded in key parts of its frame logic (AI isn't even enabled multi-threaded by default), is designed around the game engine simply blocking (busy wait) until the render is complete, and timings can get all out of whack. I know in Skyrim you can't even force Vsync in driver profiles and have it work right 100% with iPresentInterval set to 0, probably because its timings are so tight and dependent on that being enabled, perhaps causing stuff like race conditions it doesn't expect. Ever wonder why a game doesn't immediately respond to ALT+F4? If a lagging game doesn't respond immediately to ALT+F4 (such as all of the Gamebryo games I know of and most older games in general) then likely the the Windows "message pump" (event queue) is being blocked by something like just waiting for the game to finish rendering a frame. Ever wonder why a network game is so laggy in framerate with a bad connection? Same reason: it's likely blocking frames waiting on a network device. Some more technical info here: https://msdn.microso..._Considerations

 

Now what I don't know is whether the lack of multi-threadedness is due to the cross-platform Gamebryo engine--older cross-platform engines are generally extremely poor at multithreaded operations because some of their supporting consoles have convoluted ways of implementing them--or Bethesda's own adaptation of the licensed engine. But either way proper multi-threading in game engines is dark magic that is quite prohibitive to insane to implement on a cross-platform engine.

 

Oh, and one more thing:

 


"Fullscreen mode at non-native resolution means that instead of shifting graphics output to a rectangle on the screen (something relatively fast), your computer instead has to scale the picture from the game resolution to your native resolution with bicubic filtering or better (expensive!)."

This is true and untrue. Yes a non-native resolution needs to scale on a monitor for it not to show up in a box, but usually the monitor itself does the scaling unless you changed your GPU settings for your GPU to do it instead. The game engine can also do it however it wants and sometimes has its own function for scaling which will eat up more resources, usually to make things look consistent like the UI. AFAIK the TES/FO games don't do any scaling on its own and should show up in a box.


Edited by generalmx, 20 October 2016 - 02:44 AM.

  • 0


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users