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 2711 - SDL_RenderDrawLine gives different results on different render backends
Summary: SDL_RenderDrawLine gives different results on different render backends
Status: RESPONDED
Alias: None
Product: SDL
Classification: Unclassified
Component: render (show other bugs)
Version: HG 2.0
Hardware: All All
: P2 trivial
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords: target-2.0.16
: 3182 4976 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-09-01 16:23 UTC by Nicolae Berendea
Modified: 2020-11-18 16:06 UTC (History)
6 users (show)

See Also:

Attachments
test.cpp (557 bytes, text/plain)
2020-02-11 17:11 UTC, Nicolae Berendea 		Details
failed test picture (145.38 KB, image/png)
2020-02-11 17:24 UTC, Nicolae Berendea 		Details
GLES lines slightly off (325 bytes, image/png)
2020-10-26 03:18 UTC, Anthony @ POW Games 		Details
View All 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 Nicolae Berendea 2014-09-01 16:23:27 UTC 
When I draw a blended line using SDL_RenderDrawLine, the last pixel gets drawn twice so it will not have the desired color.

SDL_SetRenderDrawBlendMode(renderer, SDL_BLENDMODE_BLEND);
SDL_SetRenderDrawColor(renderer, 0, 255, 255, 128);
SDL_RenderDrawLine(renderer, 100, 100, 100, 100+100);
SDL_RenderPresent(renderer);
SDL_Delay(1000);
Comment 1 Nader Golbaz 2014-09-13 14:03:15 UTC 
What does this code do? It seems unnecessary.
from D3D_RenderDrawLines:

    /* DirectX 9 has the same line rasterization semantics as GDI,
       so we need to close the endpoint of the line */
    if (count == 2 ||
        points[0].x != points[count-1].x || points[0].y != points[count-1].y) {
        vertices[0].x = points[count-1].x;
        vertices[0].y = points[count-1].y;
        result = IDirect3DDevice9_DrawPrimitiveUP(data->device, D3DPT_POINTLIST, 1, vertices, sizeof(*vertices));
    }
Comment 2 Nicolae Berendea 2014-09-15 07:27:36 UTC 
Something similar is used to draw circles by the sdl_gfx library. So when I use aacircleRGBA (function that draws a blended circle), it has points with different color on its circumference.
Comment 3 Björn Sundin 2018-07-07 09:53:11 UTC 
This bug still exists, please fix it.
Comment 4 Nicolae Berendea 2020-01-23 21:00:45 UTC 
So, I looked into the implementation of SDL_RenderDrawLine. As Nader said, it draws the line from point a to b and then it draws another point at the end of the line (point b).
On both of my machines, the line is complete without drawing the last point - so the last point will be drawn twice thus changing color when using alpha channel.
On a virtual machine, the line is incomplete (it is missing point b) so it is necessary to draw an additional point as in the code.
Is it possible to differentiate between machines so the lines are drawn correctly in both environments?

The vm is running windows7x64. One of my machines has windows7x64; the other one windows10x64.
Comment 5 Ryan C. Gordon 2020-02-10 18:06:37 UTC 
Nicolae, I don't know if the fix in Bug #3182 will fix this too, but please test with the latest in revision control when you get a moment and let me know.

--ryan.
Comment 6 Nicolae Berendea 2020-02-11 17:11:29 UTC 
Created attachment 4203 [details]
test.cpp
Comment 7 Nicolae Berendea 2020-02-11 17:24:03 UTC 
Created attachment 4204 [details]
failed test picture
Comment 8 Nicolae Berendea 2020-02-11 17:48:50 UTC 
I've tested again. Indeed the fix doesn't work for this issue.

The issue is in the direct3d renderers. There is a point added at the end of the line.
https://hg.libsdl.org/SDL/file/3d991f099f58/src/render/direct3d/SDL_render_d3d.c#l1367
https://hg.libsdl.org/SDL/file/3d991f099f58/src/render/direct3d11/SDL_render_d3d11.c#l2274

Sometimes that point is necessary (e.g. in my vm the line is drawn fine) but not always depending on the hardware (I think).
Comment 9 Sam Lantinga 2020-02-12 07:32:15 UTC 
Ryan, I think your fix needs to be extended to the D3D renderers as well.
Comment 10 Ryan C. Gordon 2020-02-12 20:14:56 UTC 
*** Bug 4976 has been marked as a duplicate of this bug. ***
Comment 11 Ryan C. Gordon 2020-02-12 20:15:28 UTC 
*** Bug 3182 has been marked as a duplicate of this bug. ***
Comment 12 Ryan C. Gordon 2020-02-17 21:17:29 UTC 
I've backed out the recent OpenGL fix with this commit:

https://hg.libsdl.org/SDL/rev/4ba421b1e88f

...and changed this bug to target-2.0.14. Once 2.0.12 ships, we'll re-merge this patch, decide what every renderer backend _should_ do, and work on making them all work identically.

--ryan.
Comment 13 Anthony @ POW Games 2020-10-26 03:18:55 UTC 
Created attachment 4485 [details]
GLES lines slightly off

Ryan, I've just tested the latest GLES line merge on my Windows 10 Intel HD Graphics system and the lines are slightly off.  Software renderer is perfect. DX3D is OKish (it draws the last pixel twice - been that way for a while now), GL is perfect, but GLES the lines are off, being drawn 1 pixel too far forward, or too far back. Attached picture demonstrates a box being drawn using SDL_RenderDrawLinesF starting top-left and moving clockwise.
Comment 14 Anthony @ POW Games 2020-10-27 00:28:08 UTC 
Also tested on Android and the same happens with GLES lines.
Comment 15 Anthony @ POW Games 2020-11-14 02:55:40 UTC 
OpenGL and GLES lines now behave as expected (Tested on Windows & Android), thanks Ryan - I bet you'll be glad to see the back of this topic, lol.

All that remains is what the OP posted: DX3D drawing the last pixel twice - it only affects the last line in an array of lines. It's not a deal breaker for me personally, but I can see how it can cause problems for some.
Comment 16 Ryan C. Gordon 2020-11-18 16:06:05 UTC 
(In reply to Anthony @ POW Games from comment #15)
> All that remains is what the OP posted: DX3D drawing the last pixel twice -
> it only affects the last line in an array of lines. It's not a deal breaker
> for me personally, but I can see how it can cause problems for some.

Weird, I thought this was fixed, too. I'll check that again.

--ryan.