Can't reproduce on my system (latest windows 10, nvidia 650); tried 800x600@60 and 800x600@75 hz.

I can't think of an explanation, but a couple questions: do the QS brightness/contrast sliders work in both video modes? If you still get a gamma shift with both "gamma" and "contrast" cvars set to 1, it's likely something outside of QS causing the gamma difference.

Is it possible there's a different gamma setting for that video mode in your graphics driver control panel? I'm not sure if that is a feature, just guessing here.
Does it happen in any other game? 

I am still at work but will do some more work on this tonight. I doubt it's an external nvidia thing. I switch refresh rates a lot with QS and QS Admod etc. as I am working on the Xmas jam at the moment. I map and test at 72hz and then play for fun at 144. Will report back in a few hours.

I will check the sliders in both modes. And other games. 

Tested this. Happened again. But here is the weird thing: I took screenshots and they match. However, I am def noticing an increase in overall brightness.

Will keep exploring this but did not happen with .92x and Admod versions. Very strange. The brightness isn't horrible just noticeable. Here's a PDf with the screens for reference - you will not see any diff between them but thought I'd include for further discussion.

https://adobe.ly/2AQ2JDI 

Will keep exploring this but did not happen with .92x and Admod versions.
One thing is, 0.92.x and the admod build did not have refresh rate control. (I only added it in august.)

Something that might be worth checking is Fitzquake 0.85, if you don't have it already; it has the same refresh rate cvar and option in the video menu:
http://www.celephais.net/fitzquake/

I also did a bit of searching and it sounds like gamma changes can be an side effect when high-refresh rate monitors switch refresh rates - so I wonder if it could just be that?
http://www.mmo-champion.com/threads/2098378-Asus-24-quot-LED-A-Sync-MG248Q-brightness-at-different-refresh-rates 

okay, so not trying to be a proud c0ck in any way, yet, hear me out. I try to to a timedemo demo2 in QS newest, and get around 631.4fps yet in Qrack in the classic settings (which is standard quake) im getting 2200fps yet Qrack uses stupid opengl 1.3...
i'm not trying to tug a war just wondering if your glsl is batching per frame or per model? 

im using windows 10 pro 64bit nvidia 960gtx
btw 

quakeone.com/qrack test it yourself 

screenshots will not show hardware gamma correction, that correction happens only as the framebuffer is drawn to the screen. (which is why it affects the whole screen when playing quake in a window, rather than just the game window.) 

rook: yeah, I get similar results, though not as extreme, 850fps for qrack vs 500fps in QS for timedemo demo1. this is 1920x1200 on a 650gt. I don't have a good explanation. QS does well when the maps get bigger and/or there are lots of MDL's on screen, but there must be some reason it's worse on "easy" content. IIRC, DirectQ on the other hand was blazing fast on id1 content. 

Is QuakeSpasm still sleeping every frame, even in timedemos? That would cause it. 

Tested using latest source, in main_sdl.c, line 184:

if (time < sys_throttle.value) 483 fps

if (time < sys_throttle.value && !cls.timedemo) 1228 fps 

Set sys_throttle to 0 on your console before running a timedemo. 

ya setting sys_throttle to 0 im pushing 2000fps now. 

Could you add an "r_viewmodel_fov" cvar from mark_v 

it's something I want to add but didn't get to for this release. The RC does have r_viewmodel_quake (also from markv) where 1=restore winquake gun position. 

Is there any technical reason why water etc liquids textures are not mipmapped in QuakeSpasm? It's usually not very noticeable, but maps with large bodies of water (like Orl's shib1) have a lot of aliasing. 

does the water textures have TEXPREF_MIPMAP flag set? 

It's probably unchanged from Fitzquake. In Fitzquake it was done for two reasons: 1. it's not mipmapped in the software renderer (so +1 for authenticity) and 2. since the water texture is rendered every frame (when using r_oldwater 0) this means the mipmaps would also have to be recalculated which I didn't know how to do at the time (and still might not be fast enough even if I did know how.) 

But in the interest of algorithmic nerdiness...
Could you generate the mipmaps at level load and cache them? 

vkQuake (a fork of QS on Vulkan API) does support water mipmapping. Not sure how much of the Vulkan code can be translated back into OpenGL, but I suppose it could be helpful as a reference. 

Yeah - I saw that vkquake does it. It sounds like it is doable in OpenGL 1.4+ with GL_GENERATE_MIPMAP, and is done in by the GPU (if it was done on the CPU it would kill performance because the warp textures are updated every frame):
https://www.khronos.org/opengl/wiki/Common_Mistakes#Automatic_mipmap_generation

The other thing I was going to investigate was doing the warp in a fragment shader, but need to investigate whether it's faster even on lower end hardware, and if it can be made to look identical to the current warp. 

hmm odd i thought even glQuake mipmapped all textures including
water and sky textures? 

Warp in a fragment shader is faster, even on lower end hardware, and can be made look identical.

Visually it can even be superior, because normally with mipped warps the texture can shift between different miplevels as it warps, even if nothing else changes. But by taking the screen space derivatives of the unwarped texcoords and using a tex2DGrad (or equivalent) lookup, you get to avoid that and get a nice solid warping image. 

cool, thanks for the tip on tex2DGrad, will look into that.

I dug out a quick hack of RMQEngine's warp code to GLSL that I was experimenting with a year or so ago.

Snapping the texture coordinates to the nearest 1/512 (fitzquake renders the warp image into a 512x512 texture by default) seems to approximate the look of fitzquake's warp very closely:

vec2 texc_input = gl_TexCoord[0].xy;
texc_input = floor((texc_input * 512.0) + vec2(0.5, 0.5)) / 512.0;
rest of the shader

screenshots:
fitzquake render-to-texture warp
the above shader
above shader with the rounding-to-nearest-1/512 commented out

The timing is slightly off between the fitz and shader versions but they look pretty close to me otherwise, so this looks promising.