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 2018 - SDL_Render doesn't clear framebuffer between frames.
Summary: SDL_Render doesn't clear framebuffer between frames.
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: HG 2.0
Hardware: x86_64 Mac OS X 10.8
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-07 00:34 UTC by Ryan C. Gordon
Modified: 2018-12-02 17:15 UTC (History)
1 user (show)

See Also:

Attachments
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 Ryan C. Gordon 2013-08-07 00:34:47 UTC 
Right now you can have a renderer like this:

SDL_CreateWindow()
SDL_CreateRenderer()
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.

--ryan.
Comment 1 Jeffrey Carpenter 2013-12-14 03:28:56 UTC 
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.

Thanks!

[1] https://github.com/i8degrees/ttcards/issues/9
Comment 2 Jeffrey Carpenter 2013-12-14 03:32:06 UTC 
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.
Comment 3 Jeffrey Carpenter 2014-01-28 02:44:54 UTC 
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!
Comment 4 Ryan C. Gordon 2015-02-19 05:22:20 UTC 
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!
Comment 5 Ryan C. Gordon 2015-04-07 04:57:55 UTC 
(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.)

--ryan.
Comment 6 Sam Lantinga 2015-05-29 02:08:24 UTC 
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.
Comment 7 Ryan C. Gordon 2018-12-02 17:15:14 UTC 
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!

--ryan.