Bug Tracker – Bug 1055

fullscreen appears to slowdown significantly on Windows 8 with vsync ON

Last modified: 2019-12-22 20:12:39 UTC
Bug 1055 - fullscreen appears to slowdown significantly on Windows 8 with vsync ON
Summary: fullscreen appears to slowdown significantly on Windows 8 with vsync ON
Status: NEW
Alias: None
Product: Odamex
Classification: Unclassified
Component: Client (show other bugs)
Version: 0.7.x (Old)
Hardware: x86 (Windows, Linux, etc) Windows 8
: P1 minor
Assignee: Odamex Bug Reporter
Depends on:
Reported: 2014-03-28 19:57 UTC by mikaelhhome
Modified: 2019-12-22 20:12 UTC (History)
4 users (show)

See Also:


Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description mikaelhhome 2014-03-28 19:57:03 UTC
Fullscreen odamex client appears to run at 35fps no matter what I have vid_maxfps set to. I have tried 60, 70, 120 and unlimited without a noticable difference from 35.
Windowed odamex client has no problems with higher vid_maxfps
Comment 1 Mike Lightner 2014-03-28 19:58:09 UTC
Is vid_vsync on or off?
Comment 2 Mike Lightner 2014-03-28 20:06:12 UTC
I cannot reproduce this. 

Turn on vid_displayfps, and send us a shot, along with changing vid_maxfps for the cap (Default 35).  This is also what's modified in the menu.
Comment 3 Mike Lightner 2014-03-28 20:28:41 UTC
Ok this has been determined to be a slowdown issue with Windows 8 with vsync *on*.  

If vsync is off, you will not have abnormal slowdown issues.

The only thing that will fix this is the move to SDL 2.0, which you can follow along in the SDL2 branch.
Comment 4 Dr. Sean 2014-06-12 18:51:22 UTC
With vid_vsync enabled, Odamex will request a "hardware surface" from SDL (and requests a "software surface" otherwise). As the hardware surface is essentially a buffer in the video card's memory, reading and writing directly to the hardware surface is significantly slower than reading and writing to a software surface, which is a buffer in system RAM.

r4993 attempts to alleviate the slowdowns when using hardware surfaces by doing all of the rendering to a temporary software surface and then blitting to the hardware surface at the end of the frame.
Comment 5 Jer 2015-04-25 06:10:30 UTC
I can add to this that vsyc is related to the refresh rate on your monitor/lcd so that 30fps being half of a screen that is 60hz makes sense. You wont go over the refresh rate by design.  That said though, I confirm something is not right here. 

Win 8.1 nvid670 i7 windowed (vsync setting ignored) I get 200-341 fps.
When I window+vsync it futters around 19-23fps with a feeling of lag/delay.. Using built in CPU/GPU (pos) I get 29.9fps showing a freebie intel GPU outperforming a once $300 nvid card.  No noticeable difference in 32bit color on/off, wide/non, resolution, CPU utilization etc so definitely should be a setting to cure this rather than resorting to windowed or vsync off. I'll report if I stumble across a driver setting that fixes this.  My $99 Atom tablet should not perform better than my desktop when vsync is on!;)
Comment 6 Ralph Vickers 2016-11-12 03:05:09 UTC
Just tested this on the new SDL2 builds (24889a9) and cannot confirm that this is still a problem. I have a 60hz monitor and turning on vsync will drop it to about that fps and stay there no matter if i cap at 60fps or anything above. AMD fx4100 but I'm on Windows 7. Can one of the Windows 8 guys that posted here try this out? If no responses - I'll have a couple other people test and then close the bug in a few days.
Comment 7 HeX_Vulture 2019-12-22 20:12:39 UTC

Can we get information regarding if this bug is still present in 0.8.1 or a newer version? If not we will close the bug due to lack of testable hardware and feedback.