Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SDL_Render doesn't clear framebuffer between frames. #1006

SDLBugzilla opened this issue Feb 10, 2021 · 0 comments

SDL_Render doesn't clear framebuffer between frames. #1006

SDLBugzilla opened this issue Feb 10, 2021 · 0 comments


Copy link

SDLBugzilla commented Feb 10, 2021

This bug report was migrated from our old Bugzilla tracker.

Reported in version: HG 2.0
Reported for operating system, platform: Mac OS X 10.8, x86_64

Comments on the original bug report:

On 2013-08-07 00:34:47 +0000, Ryan C. Gordon wrote:

Right now you can have a renderer like this:

SDL_RenderSetLogicalSize(something at a different aspect ratio)

Then when rendering into this logical-sized viewport, SDL doesn't clear the unused portion of the screen. This means that the Steam Overlay will accumulate trash in these areas.

Happens on Mac, Linux, Windows, Direct3D or OpenGL.


On 2013-12-14 03:28:56 +0000, Jeffrey Carpenter wrote:

I would like to share that I may be experiencing a related issue that is occurring here, documented at my game's project issues page [1]. The two differences in my situation: a) this is occurring only on Mac OS X -- v10.9.0 "Mavericks" -- whereas it is fine under Windows 7; b) no Steam Overlay.


[1] i8degrees/ttcards#9

On 2013-12-14 03:32:06 +0000, Jeffrey Carpenter wrote:

Oops, I jumped the gun there!

I would like to note that I am using SDL_RenderSetLogicalSize in my game to scale up by a factor of two from 384x224x32.

On 2014-01-28 02:44:54 +0000, Jeffrey Carpenter wrote:

Following up on the report I sent a while back: you can disregard it!

For the possible help this may provide to others: my issue is taken care of simply by ensuring that the entire game window is always filled with a color at all times during the game's main loop -- I use SDL2's renderer API for doing a black color fill right after processing SDL's events & updating the current game state. The solution resolves the artifact garbage rendering issue in OS X upon entering full-screen without any ill effects in my other supported platform (Windows).

No idea why the issue never has shown itself on Windows OS, but I'm happy accepting things as is! :-)

P.S. My apologies for my original posting in this bug thread. Looking back, I probably ought to have filed a new bug all together and perhaps referenced this report as a possible relation...

Thanks. Cheers!

On 2015-02-19 05:22:20 +0000, Ryan C. Gordon wrote:

Marking a large number of bugs with the "triage-2.0.4" keyword at once. Sorry if you got a lot of email from this. This is to help me sort through some bugs in regards to a 2.0.4 release. We may or may not fix this bug for 2.0.4, though!

On 2015-04-07 04:57:55 +0000, Ryan C. Gordon wrote:

(sorry if you get a lot of copies of this email, I'm marking several bugs at once)

Marking bugs for the (mostly) final 2.0.4 TODO list. This means we're hoping to resolve this bug before 2.0.4 ships if possible. In a perfect world, the open bug count with the target-2.0.4 keyword is zero when we ship.

(Note that closing a bug report as WONTFIX, INVALID or WORKSFORME might still happen.)


On 2015-05-29 02:08:24 +0000, Sam Lantinga wrote:

I have a fix for this, but it involves switching the logical size handling over to a target texture. I'll put this in for 2.0.5, after review.

On 2018-12-02 17:15:14 +0000, Ryan C. Gordon wrote:

This appears to have changed at some point (or maybe I was always wrong about this...?).

SDL_RenderClear(), in all renderers as far as I can tell, clears the entire framebuffer, instead of clamping it to the logical size with glScissor(), etc.

So we're good here!


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

1 participant