Auto rendering resolution is broken

[vnctdj]

As the title says, automatic rendering resolution is not working as it should anymore.
It seems that 103b73d is the culprit.

What I have done :

1. Open PPSSPP, default window size.
2. Switch to fullscreen.
3. Switch back to small window.
   The result :
   

[hrydgard]

Ah, doh. Fixing, another silly little mistake..

[vnctdj]

Not really fixed unfortunately...
The displayed message is now correct but it is actually lying !

How to reproduce :

1. Start PPSSPP with default window size (x2).
2. Change window size (for example x4).
3. You can notice that the rendering resolution is still x2 even though the on-screen message has changed...

PS : It seems I can't re-open my own issue :/

[hrydgard]

Thank you for your patience @vnctdj , I really need to clean up this code :P One more try coming soon...

[hrydgard]

OK, with that fix I can't reproduce anymore. Let me know if you find anything else..

[vnctdj]

I'm afraid this new commit hasn't changed anything for me...
Auto rendering resolution seems to keep the previous resolution :/
It's obvious when you look at an image which has precise details.

[hrydgard]

I don't know what to say. I tried both in D3D and GL.

I set window size to 1x and render resolution to auto. It's rendering at 480x272. Pressed F11. It's now fullscreen and is rendering at 2880xwhatever, and the picture is indeed sharp. Pressed F11 again. Back to a window, it's back to rendering at 480x272.

What are you doing?

[vnctdj]

Oh ! I have found the problem !
-> Auto rendering resolution is only broken when a postprocessing shader is enabled.

[LunaMoo]

There seems to be something fishy happening with postprocessing shaders even with manually selected rendering res, I made a very resolution sensitive scanline shader that simply darkens every second line going like this:

vec3 color = texture2D(sampler0, v_texcoord0.xy).xyz;
float SLsize = 1.0;
vec3 colorSL = color * 2.0;
float rey = (1.0 / SLsize / u_pixelDelta.y);
float posSy = v_texcoord0.y*(rey/1.0);
float lineSy = mod(posSy,2.0);
color=color-lineSy;
color=mix(color,colorSL,0.6);
gl_FragColor.xyz=color;
gl_FragColor.a = 1.0;

which uses "OutputResolution=True" and even with manually selected rendering resolution as soon as I change window size it get's messed up, it wasn't earlier:]. I have to manually select rendering res after changing window size to correct it again ~ that's with v1.0.1-2788-gd3b265a

Tiny samples how it should look:

and how it looks after changing window size now:

Edit:
I kind of found a fix, but don't know how to deal with part of it.
Assuming postprocessing shaders using "OutputResolution=True" + xN rendering res are affected by same thing as "auto" rendering res with shaders that doesn't use it, I noticed that the change does actually exist when going between window/fullscreen, however it lags behind one "change" - "thanks" to recent nvidia driver bug workaround.:/ In case it's hard to understand Window->Fullscreen will keep window rendering res for fullscreen, then going back will set fullscreen res to window.

Window xA to window xB switch is different and broken by lacking UpdateSize(); in FramebufferManagerCommon::BeginFrame() - so that's an easy fix, after additionally disabling that nvidia bugginess workaround it fully works for me, but nvidia users with this crash will not be too happy from reverting their workaround. I tried a few things to fix it keeping the nvidia thing, but failed misreably:|.

Next day edit:
If (in addition to the missing UpdateSize(); mentioned in previous edit) I exclude all cases of the ShowWindow() from the workaround so pretty much put GL_Resume()/GL_Pause() around it, it works, but that might as well be the only parts which had to be paused to stop nvidia crashes or maybe something else like HandleSizeChange() is the cause of that crash?:/
Both desktops I currently have got amd gpu's, eventually intel igp, so I can't test anything with this. Will just wait and hope my findings helped at least a bit.

[hrydgard]

Thanks for your investigation! That would explain why I couldn't reproduce it, I didn't try with post proc. I will investigate.

[hrydgard]

@vnctdj @LunaMoo That should have taken care of the issue when postprocessing is enabled, too.

[LunaMoo]

Cool, thanks, can confirm it works fine here.:)

[vnctdj]

I confirm the fix, too :)
Thank you @hrydgard !
And also thank you @LunaMoo for your testing !