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 4752 - SDL_RenderSetClipRect occasionally breaks SDL_RenderClear even though clipping is unset
Summary: SDL_RenderSetClipRect occasionally breaks SDL_RenderClear even though clippin...
Status: ASSIGNED
Alias: None
Product: SDL
Classification: Unclassified
Component: render (show other bugs)
Version: 2.0.10
Hardware: All All
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords: target-2.0.12
Depends on:
Blocks:
 
Reported: 2019-08-03 18:11 UTC by Ellie
Modified: 2020-07-20 18:12 UTC (History)
3 users (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 Ellie 2019-08-03 18:11:39 UTC 
I am seeing breakages of SDL_RenderClear when I use SDL_RenderSetClipRect in other, unrelated code parts. Of course I could just be setting the clip rectangles wrong, but I have now gone as far as grep for every use of SDL_RenderClear in my code, and preface each with:

sdl.SDL_RenderSetClipRect(renderer, None)   # PySDL2's equivalent to SDL_RenderSetClipRect(renderer, NULL)

... and even then, the SDL_RenderClear often leaves rectangular areas with uninitialized memory. And when I comment out the use of SDL_RenderSetClipRect in other places that is not NULL-rectangles that apply a clip, then all the SDL_RenderClears suddenly work!

Based on this it seems like the SDL2 clip code may have a bug where even if the clip is disabled again it will affect follow-up render clears. It may or may not need a render target switch in between to materialize (but the clip isn't supposed too change if render target changes, right? At least not if it was working properly)

I see this both on Linux desktop (Fedora x64, intel integrated gpu with OpenGL SDL_Renderer) and on Android with EGL SDL_Renderer
Comment 1 Ellie 2019-08-12 10:54:10 UTC 
Ok I just verified that with the software renderer this WORKS (bug does NOT reproduce) so this seems to be an OpenGL/EGL backend issue. I went extensively through all scenarios where this breaks in my apps, and in software mode, apart from being super slow, there wasn't a single render error and all the render clear was unclipped as it is supposed to be.

I also get way more of these render errors with Android/EGL, so Desktop OpenGL/Linux seems affected but for some reason less so.

If someone provided me with a patch with more debug output via the usual logging mechanism that also ends up showing on Android's logcat (since it shows up most on that platform) then I could give it a run and return the output to you, if that helps with anything
Comment 2 Sylvain 2019-08-13 14:16:36 UTC 
Try to disable batching to see what happen ?
And I would try to reduce the issue to a c testcase.


To make sure, on desktop it fails with both opengl, and opengles2 ?

If you select opengles2, some place to put debug traces:

https://hg.libsdl.org/SDL/file/8e299f937b6c/src/render/opengles2/SDL_render_gles2.c

find: SDL_RENDERCMD_SETCLIPRECT, cliprect, cliprect_enabled_dirty


( maybe related to #4457, https://hg.libsdl.org/SDL/rev/32839175c0e4 )
Comment 3 Sylvain 2019-08-27 16:31:12 UTC 
Maybe a duplicate / fixed by bug 4766. Is this still happening ?
Comment 4 Alex Szpakowski 2019-08-27 22:57:16 UTC 
This should be fixed by https://hg.libsdl.org/SDL/rev/d465f3a64af6
Comment 5 Ryan C. Gordon 2019-09-20 20:47:39 UTC 
We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.
Comment 6 Ryan C. Gordon 2019-09-20 20:48:41 UTC 
We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.
Comment 7 bugmenot_0 2020-07-20 10:34:54 UTC 
According to https://wiki.libsdl.org/SDL_RenderClear:

> This function clears the entire rendering target,
> ignoring the viewport and the clip rectangle.

This was broken in (probably) all backends, because it (wrongfully) respected the clip-rectangle.

As mentioned in this discussion, it was then fixed in OpenGL backends by https://hg.libsdl.org/SDL/rev/d465f3a64af6 .

However, the same issue appears to remain in many other popular backends like D3D9 (and potentially others), affecting real applications:

https://github.com/Tyyppi77/imgui_sdl/issues/6#issuecomment-631004831

- So this is *still* an unresolved issue, even for the latest SDL2, for other backends.


Note: I'm not using any of the affected platforms, so I can only assume that this is a bug, based on reports by others, and code-review. A unit-test should be designed to catch this sort of problem.