We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4358 - direct3d renderer becomes invalid on windows resize
Summary: direct3d renderer becomes invalid on windows resize
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: render (show other bugs)
Version: HG 2.0
Hardware: All Windows 10
: P2 major
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-11-05 00:18 UTC by Anthony @ POW Games
Modified: 2018-12-03 02:04 UTC (History)
3 users (show)

See Also:

Attachments
This test code will reproduce the bug (884 bytes, text/plain)
2018-11-05 00:18 UTC, Anthony @ POW Games 		Details
This test code shows the problem more clearly (898 bytes, text/plain)
2018-11-08 12:44 UTC, Anthony @ POW Games 		Details
patch that frees all vbos before reset is called (689 bytes, patch)
2018-11-19 19:59 UTC, Malte Kießling 		Details | Diff
View All 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 Anthony @ POW Games 2018-11-05 00:18:32 UTC 
Created attachment 3446 [details]
This test code will reproduce the bug

This only happens on the Direct3D renderer when using:

	SDL_SetHint(SDL_HINT_RENDER_LOGICAL_SIZE_MODE, "overscan");

and the window is a different aspect to the SDL_RenderSetLogicalSize(). 

It may affect other drawing methods, but I've only been using SDL_RenderFillRect.

It works ok on OpenGL, GLES, and software renderers. It works ok when using letterbox mode.
Comment 1 Anthony @ POW Games 2018-11-08 12:42:59 UTC 
revising this bug since I've found it's not related to scaling.

This is quite serious. 2.0.9 release works OK, but this happens in the current mercurial source. 

No special conditions needed to trigger bug. Simply create a direct3d renderer and resize the window and all drawing stops. SDL_RenderPresent can't return an error, but it does set one: Present(): INVALIDCALL

Also maybe related, but when the window is fullscreen-desktop, alt-tabbing away causes the window to not restore and stay the size of a tab on top-left of the screen. I've submitted a recent bug that may also be related:
Comment 2 Anthony @ POW Games 2018-11-08 12:44:20 UTC 
Created attachment 3464 [details]
This test code shows the problem more clearly
Comment 3 Ozkan Sezer 2018-11-08 13:50:42 UTC 
(In reply to Anthony @ POW Games from comment #1)
>   2.0.9 release works OK, but this happens in the
> current mercurial source. 

Changing version to hg/2.0 then.
Comment 4 Malte Kießling 2018-11-18 23:10:25 UTC 
I also managed to observe this with the current hg source.

For me the drawing does not stop however, the size of the area drawn to just becomes that of the smallest size of the window. If i resize it back to something bigger the rest just stays black. 
It is as if constantly calling SDL_RenderSetViewport with the size of the smallest window. 
I also tried calling SDL_RenderSetViewport  explicitly after receiving the resize event without success. 

Tested with SDL_ SDL_RenderDrawLine and SDL_RenderCopyEx.
Comment 5 Malte Kießling 2018-11-19 19:59:33 UTC 
Created attachment 3500 [details]
patch that frees all vbos before reset is called

I could identify the problem. 

When D3D_Reset is called, it does not release the vertex buffers. 
As a result, IDirect3DDevice9_Reset fails with D3DERR_INVALIDCALL
(https://docs.microsoft.com/en-us/windows/desktop/direct3d9/d3dpool, at the end of the D3DPOOL_DEFAULT notes)

To fix this, vbos need to be created either with D3DPOOL_MANAGED or be explicitly freed. 

I attatched a patch that does use the latter. It solves the problem, at least on my machine. 
As far as i can see, the vbos are allocated as they are needed anyways, so that, to me, appears as the cleaner solution.  

~mkalte
Comment 6 Ryan C. Gordon 2018-11-22 08:32:35 UTC 
> To fix this, vbos need to be created either with D3DPOOL_MANAGED or be
> explicitly freed. 

Whoops, this is a good catch. I'll apply this fix soon.

--ryan.
Comment 7 Ryan C. Gordon 2018-12-03 02:04:46 UTC 
This patch is now https://hg.libsdl.org/SDL/rev/088f52a4e1b2, thanks!

--ryan.