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_RenderSetClipRect bug with openGL and a Texture as render target #1616

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Closed

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: 2.0.1
Reported for operating system, platform: Windows 7, x86_64

Comments on the original bug report:

On 2014-08-23 20:55:33 +0000, E. van Putten wrote:

Noticed that SDL_RenderSetClipRect flips the Y-coordinates on some platforms.

Background: I'm using the clipping to implement some GUI 'windows' in my app. Found that SDL_RenderSetClipRect does not always clip where you'd expect it.

Further complications: I'm using a texture as render target. So I clip while rendering the off-screen texture. Then finally copy the entire texture to the screen (or output window).

Disclaimer: so it might be that SDL_RenderSetClipRect works completely fine when clipping the final screen (or output window) target. But I didn't try that.

Steps to reproduce:

  • Create a texture that's also a render target
  • Performing clipping with SDL_RenderSetClipRect
  • Draw some things using SDL_RenderCopy
  • Copy the entire texture to the screen
  • Observe correct or incorrect result (*)
  • Try this on different machines!

Workaround:

You'd expect this code:
SDL_RenderSetClipRect(hRenderer,&MyWinRect);

But some platforms need this 'adjustment':

SDL_Rect rClip = MyWinRect;
if (ClipRectRpiFix) {
rClip.y = ScreenHeight - rClip.y - rClip.h;
}
SDL_RenderSetClipRect(hRenderer,&rClip);

But I don't know when to apply it...
Nor which one I'd normally need.

I also don't know if it's expected to simply pass the unmodified 2D coordinates to SetClipRect as you would with other functions like FillRect and RenderCopy.

So far I've tried with 3 computers:

Raspberry Pi:
YES (workaround needed)

Windows 7/x64 PC (with simple nVidia 9500 GT card):
NO

Somebody elses laptop (Acer, but forgot to write down the specs):
YES

Sorry for the lack of further information.
For me the workaround fixes things meanwhile, but I'm sure others must have been seeing this as well...

On 2014-08-23 20:59:38 +0000, E. van Putten wrote:

BTW: It might very well be that the bug is not in SDL at all.
But in underlying video card drivers.

On 2014-08-24 07:05:18 +0000, Sam Lantinga wrote:

The clip rect is intended to use top-left origin like all the other API calls. Can you attach a simple example and which renderers and operating systems are having the problem?

Thanks!

On 2014-08-24 14:11:29 +0000, E. van Putten wrote:

Created attachment 1847
Small program to reproduce bug on Raspberry Pi (and possible other systems)

This small program demonstrates the bug.

Fills a texture using the red color, then clips a rectangle (top/left quadrant of the screen) and fills the clipped interior using a yellow color.
Then the texture is copied to the screen and the program waits for a few seconds.

Same. But now without the texture (rendering directly to the screen).

In both cases you'd expect a yellow rectangle in the top/left area of the screen.
On the systems affected by the bug, you will see the first rectangle appearing at the bottom/left corner instead (incorrect),
followed by one appearing at the top/left corner (correct).

On 2015-01-05 09:22:18 +0000, Tero Lindeman wrote:

This is happening on a Linux/OpenGL setup when rendering to a texture. Might have something to do with the OpenGL coordinate system which indeed has (0,0) on bottom-left.

On 2015-02-02 23:27:44 +0000, Alvin wrote:

Created attachment 2016
Texture clipping test

I am also experiencing this bug as well. I have written a similar test program as the one already attached. However, this test program is not specific to the Raspberry PI.

The attached program sets a 100x100 clipping rectangle at the origin and fills the whole dimensions of the texture in red. Effectively making a 100x100 red square at the origin. Clipping is then turned off and a blue 50x50 square is drawn using SDL_RenderFillRect() at the origin.

I have tested two Linux systems. One that uses the nvidia driver and another that uses the integrated intel driver (HD 4000). Both draw the red square at the bottom-left and the blue square at the top-left.

What I have noticed is that the issue does not occur when the renderer's default target is used directly (omitting the intermediate texture and set the clipping on the renderer's default target). Both the red and blue squares at drawn at the top-left.

For instance, commenting out lines 77 and 137 in my test program will use clipping on the renderer's default target.

Could this be an issue with how the SDL_Texture initialised internally?

I have tested the opengl, opengles and opengles2 renderers. All three exhibit the same behaviour: the texture's clipping origin is at the bottom-left.

My tests have used SDL2 from Mercurial, bb0b744fd1a6.

On 2015-02-04 15:05:56 +0000, Alvin wrote:

Created attachment 2017
Fixes clipping origin (may have side-effect with a viewport)

This is a patch that fixes the clipping origin (was bottom-left). The origin is now the top-left.

The patch applies only to the "opengl" and "opengles2" render drivers. It does work using the "opengles" render driver, however, the origin of the default render target appears to be the bottom-left. Therefore, this patch does not touch the "opengles".

There may be a side-effect when using a viewport. The patch uses the Y coordinate of the clipping rectangle verbatim. The origin line of code mapped the Y coordinate of the clipping rectangle to the bottom-left and took "renderer->viewport.h" into consideration. I tested with and without the patch and it appears that the clipping rectangle doesn't fully follow the viewport. Perhaps linked to bug 2535?

Someone more familiar with how the viewport interacts with and without a clipping rectangle may want to review the effect of this patch.

On 2015-04-26 14:05:22 +0000, Marcel Bakker wrote:

Created attachment 2136
openGL renderer + texture as target + SDL_RenderSetClipRect

I can also confirm that SDL_RenderSetClipRect() is broken
, when openGL is used with a Texture as rendering target.
As discussed above, the default target for openGL has a bottom-left origin.
But textures as target seem to use top-left as an origin.

SDL's current openGL clipping code assumes a default target, adjusting the clip-rect to a bottom-left origin.
, breaking SDL_RenderSetClipRect() when used with a Texture as rendering target.
Alvin's patch fixes the Texture as target problem
, but by removing the bottom-left origin code, this moves the clipping-bug to the default target.

This proposed patch checks for a default target and use bottom-left as origin
, else use top-left as origin.

note : only openGL was tested, assumed same behavior for GLES2...

On 2015-04-26 15:12:03 +0000, Marcel Bakker wrote:

Created attachment 2137
openGL renderer + texture as target + SDL_RenderSetClipRect

note : only openGL was tested, assuming same behavior for GLES/GLES2...

On 2015-04-27 13:30:12 +0000, Marcel Bakker wrote:

Changed the summary to better reflect the problem.

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

Fixed, thanks!
https://hg.libsdl.org/SDL/rev/1d13a878b066

On 2015-08-10 17:50:15 +0000, Diego wrote:

Why is the current patch using bottom-left for origin for default targets? To be consistent with SDL, shouldn't all origins be top-left?

On 2015-08-10 17:51:19 +0000, Diego wrote:

Reopening bug because I think all origins should be top-left.

On 2015-10-28 16:07:42 +0000, Marcel Bakker wrote:

Created attachment 2291
additional patch

On 2015-10-28 16:08:56 +0000, Marcel Bakker wrote:

Hello again,

I'm afraid Diego is correct, i never did test Sam's commit.
I worked from my own patch, only now whilst checking a new problem i noticed clip-rect was still broken.
Yes, silly me... but,..

The commit : https://hg.libsdl.org/SDL/rev/1d13a878b066
, is a mix of a viewport bug-fix and this clip-rect bug-fix into 1 commit.
That broke this patch for the clip-rect bug.

I think the additional patch gives the expected (with viewport)clipping behavior.

On 2015-11-05 01:09:31 +0000, Diego wrote:

I tested the patch using OpenGL and OpenGLES2. It works as expected from the top-left.

On 2015-12-28 20:17:08 +0000, Ryan C. Gordon wrote:

(In reply to Marcel Bakker from comment # 13)

Created attachment 2291 [details]
additional patch

This patch is now https://hg.libsdl.org/SDL/rev/f9cd179cf50e, thanks!

--ryan.

On 2015-12-29 17:38:36 +0000, Martin Gerhardy wrote:

I'm still having problems with scissors on gl and gles2, the same cliprects works perfectly if I use the software renderer.

On 2015-12-29 17:40:40 +0000, Martin Gerhardy wrote:

Unfortunately I don't have a small code sample extracted - but compiling caveexpress and running it via "./caveexpress -ui_push editor" will render the selector ui elements on the left side empty. Doing the same with "./caveexpress -set renderer software -ui_push editor" will show the entries perfectly. Tested this on linux - will do a directx test in a few minutes

On 2015-12-29 17:51:33 +0000, Martin Gerhardy wrote:

DirectX renderer works fine when using clip rects with sdl renderers for caveexpress

On 2015-12-29 18:19:00 +0000, Diego wrote:

I just tested the latest from hg. It worked fine for me. The origin was from the top-left. I inserted the following code at line 274 of testdraw2.c to test gl, and at line 143 in happy.c to test gles2.

SDL_Rect r = {10,20,100,200};
SDL_RenderSetClipRect(renderer, &r);

On 2015-12-30 06:37:35 +0000, Ryan C. Gordon wrote:

Reopening for now.

--ryan.

On 2016-03-05 23:45:45 +0000, Marcel Bakker wrote:

hello,

Martin Gerhardy,
I don't know your project caveexpress also not much about openGL
, but after a quick look i suspect you are mixing openGL and SDL too much.

You set your own textures in FrameBuffer::bind(), but use SDL_RenderSetClipRect to set the scissors.
SDL doesnt known about your texture and will not detect it, only if you have set it via SDL_SetRenderTarget.

On 2016-04-16 23:20:35 +0000, Richard Russell wrote:

I'm pretty certain there's still something not right. I'm seeing the clip rectangle inverted with 2.0.4 and GLES (OpenGL is OK; I've not tried GLES2), using a texture as the render target and rendering using SDL_RenderCopy.

There's a remark in comment # 6 about GLES needing different treatment, but I'm unsure of the details.

On 2016-04-17 11:09:55 +0000, Richard Russell wrote:

Actually on further investigation I don't think what I'm seeing is a problem with the clip rectangle at all, but another manifestation of bug # 3233. Because that bug causes graphics to be plotted upside-down, I am inverting my y-coordinate. In 2.0.3 this worked around both # 3233 and # 2700 and all was well. However in 2.0.4 # 2700 is fixed, but # 3233 isn't, so my workaround is causing the clip rectangle to appear to be inverted!

On 2016-05-20 11:33:09 +0000, BQ wrote:

Hi, I still seem to be having an issue with this. I'm using SDL2 HEAD via Homebrew on OSX. I have a cross-platform GUI library with implementations in SDL2, OpenGL, SFML2 and Allegro5. I only see this issue in SDL2, the others clip fine. The GUI library assumes top-left screen origin. It seems this isn't at driver level as GL and SFML2 work fine.

Library: https://github.com/billyquith/GWork
If you'd like to see this then the following BASH script will build and run the SDL2, GL and SFML2. SFML2 uses GL.

---->8---->8---->8---->8---->8---->8---->8----
#!/usr/bin/env bash
git clone -b SDL2 --depth=1 https://github.com/billyquith/GWork.git gwork
cd gwork
mkdir build_sdl2 && cd build_sdl2
cmake -G Ninja -D RENDER_SDL2=ON ..
ninja
cd ..
mkdir build_gl && cd build_gl
cmake -G Ninja -D RENDER_OPENGL=ON ..
ninja
cd ..
mkdir build_sfml2 && cd build_sfml2
cmake -G Ninja -D RENDER_SFML2=ON ..
ninja
cd ..
cd build/bin
./GworkSDL2Sample&
./GworkOpenGLSample&
./GworkSFML2Sample&
---->8---->8---->8---->8---->8---->8---->8----

On 2017-03-12 13:00:11 +0000, BQ wrote:

(In reply to BQ from comment # 25)

Hi, I still seem to be having an issue with this. I'm using SDL2 HEAD via
Homebrew on OSX. I have a cross-platform GUI library with implementations in
SDL2, OpenGL, SFML2 and Allegro5. I only see this issue in SDL2, the others
clip fine. The GUI library assumes top-left screen origin. It seems this
isn't at driver level as GL and SFML2 work fine.

The following workaround, as mentioned above, works for me.

SDL_Rect rClip = MyWinRect;
if (ClipRectRpiFix) {
rClip.y = ScreenHeight - rClip.y - rClip.h;
}
SDL_RenderSetClipRect(hRenderer,&rClip);

On 2017-03-20 16:23:30 +0000, Marcel Bakker wrote:

Created attachment 2706
test renderers with SDL_ClipRectangle

Hello BQ,
Could you provide a test case?
Don't think people here will use your library to debug the problem.
I attached a small test, but it might not cover your use case.

  • The test file yields a new bug in the software renderer clipping
    , not related to this bug entry.

On 2017-08-05 08:58:39 +0000, BQ wrote:

As of version 2.0.5, this bug appears to have been fixed. I do not know the reason for this.

Notes on bug ticket on my project:
billyquith/GWork#18

My fix:
billyquith/GWork@5017829

On 2017-08-14 05:14:02 +0000, Sam Lantinga wrote:

This bug should be fixed. If there are any cases that are still not correct, please enter a new bug with a test case so we can reproduce it.

Thanks!

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

No branches or pull requests

1 participant