有 13 人觉得这篇评测有价值
有 1 人觉得这篇评测很欢乐
不推荐
过去 2 周 0.0 小时 / 总时数 6.9 小时
发布于:2019 年 10 月 18 日 下午 5:16
更新于:2019 年 10 月 18 日 下午 5:17

Does this tool generally work at what it's meant to do? Yeah. But it's got issues.

The single biggest issue with this tool is the constant background CPU utilization; it's simply excessive. On my machine, while the Borderless Gaming tool is ostensibly "idling" in the background, its process actually cycles between using roughly 100% of one CPU core for ~3 seconds, then goes idle for ~3 seconds, and then repeats, without end. So, whatever methodology is being used to do the window detection stuff, it's clearly too heavyweight to realistically justify itself.

And then to add to the above, the developer of this tool has effectively abandoned it since mid-2017. So improvements are highly unlikely to ever happen. Oh and did I mention that this $4 offering on Steam can be obtained for free, as it's an open source project hosted on GitHub? Yeah...

I would highly recommend that potential users of this tool (a) download it directly from the project's website instead of paying for it on Steam, particularly given that it contains no actual Steam integration, and in fact works best in isolation from Steam; and (b) consider an alternative tool for the job instead of this one.

Direct Free Download via GitHub:
https://github.com/Codeusa/Borderless-Gaming/releases

Alternatives:
https://alternativeto.net/software/borderless-gaming/
https://pcgamingwiki.com/wiki/Glossary:Borderless_fullscreen_windowed
这篇评测是否有价值? 欢乐 奖励
开发者回复:
Andrew  [开发者] 发布于:2019 年 10 月 22 日 下午 10:42
The software contains trading cards, cloud saves, and automatic updates. There is deep integration. Also yes, the software is free, as clearly shown in the store.
1 条留言
Crashed 2019 年 10 月 22 日 下午 11:11 
There are two issues that cause the CPU usage.

First issue is that the software is constantly polling for new windows, and the more windows you have the bigger the overhead.

Second issue, it's written in .NET Framework which adds its own inefficiency.

I could suggest that a HSHELL_WINDOWCREATED hook would be able to sleep indefinitely, only waking when the hook fires when a top-level window is created. If responding instantly causes trouble, it could spin up a thread that waits a configurable delay before hacking the window style and position/size.