Software renderer + viewport + cliprectangle

[SDLBugzilla]

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• clip test v2 (clippy.c, text/plain, 2017-04-07 12:25:17 +0000, 15503 bytes)

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

Comments on the original bug report:

On 2017-03-20 16:29:24 +0000, Marcel Bakker wrote:

The software renderer does not clip correct when a viewport is used.
A test that shows this can found in bug id 2700 (#1616)
link: https://bugzilla.libsdl.org/attachment.cgi?id=2706

On 2017-04-07 12:25:17 +0000, Marcel Bakker wrote:

Created attachment 2714
clip test v2

After adding a test file to bug 2700 (#1616), this bug popped up.
Completing the test file a little more, showed a few more rare use
case problems. I could split this up into multiple reports if needed,
copy-pasted from test file:
(note that proposed fixes have not been tested)

---

observed problems: (some of these have been reported)

-software render + viewport + clip_rectangle
, test 3,4,7 and 8 show this.

• bug ID # 3612 (Software renderer + viewport + cliprectangle #2419) (SDL_render_sw.c, line 368, SW_UpdateClipRect(): viewport offset is missing)

-software render + viewport + SDL_RenderReadPixels
, the read offset is incorrect when a viewport is used
, can test this with taking a screen shot from test 3,4,7 and 8.

• (SDL_render_sw.c, line 842: viewport offset is added a second time)

-Windows 7 opengl + SDL_RenderReadPixels
does NOT correspond to what is shown
, looks like its always a frame behind
, screen shots taken will be an image from the previous test... press 'r' to force a repaint

• ?Related? bug ID # 3619 (SDL_RenderReadPixels result is unspecified and fails testautomation #2426) (different OS, debian did gave correct results for me)

-SDL_SetRenderTarget(ren, target) + logical size
a logical size is set by default
, test 4 and 6 shows this, a logical-size is detected and used as a backup (line 212 in here)
, only the first time it is drawn correctly, press 'r' to refresh

• (SDL_render.c, line 1124: renderer->logical_w/h should be initialized to 0, not the texture->w/h)

-opengl(es2) render + scale
default render and target texture give different visual results
, test 5,6 and 7,8 show this.
+

Draw primitives problems:
note : SDL_RenderDrawRect() bugs are SDL_RenderDrawLines(multiple lines) bugs in reality.

direct3d - windows {

• SDL_RenderDrawRect
  top-left + bottom-left pixels are drawn 2 times
  }
  software - all {
• SDL_RenderDrawLine
  1 pixel lines are not drawn
  }
  opengl(es2) - debian 8 {
• SDL_RenderDrawLine
  1 pixel lines are not drawn (gles2 does draw them)
• SDL_RenderDrawRect
  bottom-left pixel is drawn 2 times
  bottom-right pixel is NOT always drawn
  }
  all - renderers - tested {
• SDL_RenderDrawRect
  00 width/height draws a negative 22 rectangle
  1*1 width/height is not drawn

• SDL_RenderDrawRect() probably needs a few special checks...
  }

On 2017-04-08 14:52:51 +0000, Marcel Bakker wrote:

I missed a few :

software render + SDL_RenderFillRect
A w or h with 0 will always MAX() up to 1 - SW_RenderFillRects() uses MAX(w/h,1)
, tests 1 and 2 show this

software render + viewport + clip-rect
It seems the software renderer is using SDL_SetClipRect(), to set the viewport
, this results in broken behavior if the clip-rect is used in combination with a viewport.
, adding any draw call after the clip-rectangle usage in the test file, will ignore viewport settings and draw anywhere.

On 2017-06-04 15:13:06 +0000, Daniel wrote:

Bug # 3324 (#2156) has a patch to fix the SDL_RenderReadPixels problem with software renderer.

[1bsyl]

Closing, because it gives same results between opengl/gles2/software renderers

[1bsyl]

re-open because this actually fails:

SDL_SetRenderTarget(ren, target) + logical size
a logical size is set by default
, test 4 and 6 shows this, a logical-size is detected and used as a backup (line 212 in here)
, only the first time it is drawn correctly, press 'r' to refresh

[1bsyl]

@mason-wheeler (are you the correct person?)

maybe we should revert this:
libsdl-org/SDL-historical-archive@c756245
because of the previous test (when pressing refresh, it changes the rendering).
and/or fix in a different way ?

[1bsyl]

Closing this. The test-case only shows an issue because it sets the scale or not, based on the value of logical w/h (0 or not).
Going to address the issue in specific ticket (4213)