SDL_RenderDrawLine end-point behavior broken on Linux

[SDLBugzilla]

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Test case to demonstrate end-point behavior on Linux (endpoint.c, text/x-csrc, 2017-03-05 10:38:06 +0000, 1975 bytes)

Reported in version: 2.0.5
Reported for operating system, platform: Linux, All

Comments on the original bug report:

On 2017-03-05 10:38:06 +0000, Richard Russell wrote:

Created attachment 2702
Test case to demonstrate end-point behavior on Linux

SDL_RenderDrawLine is documented as drawing the line "to include both end points". Whilst this works correctly on Windows and Mac OS-X, it does not work on Linux (in all cases using the OPENGL renderer). In particular, specifying the same coordinates for both end-points results in nothing being drawn at all! This appears to be due to the following code in sdl_render_gl.c:

#if defined(MACOSX) || defined(WIN32)
        /* Mac OS X and Windows seem to always leave the last point open /
        data->glVertex2f(0.5f + points[count-1].x, 0.5f + points[count-1].y);
#else
        / Linux seems to leave the right-most or bottom-most point open */
        x1 = points[0].x;
        y1 = points[0].y;
        x2 = points[count-1].x;
        y2 = points[count-1].y;

        if (x1 > x2) {
            data->glVertex2f(0.5f + x1, 0.5f + y1);
        } else if (x2 > x1) {
            data->glVertex2f(0.5f + x2, 0.5f + y2);
        }
        if (y1 > y2) {
            data->glVertex2f(0.5f + x1, 0.5f + y1);
        } else if (y2 > y1) {
            data->glVertex2f(0.5f + x2, 0.5f + y2);
        }
#endif

It seems to me unlikely that OPENGL works differently on Linux by design, so I am doubtful that this code is any longer required (if it ever was).

I have attached a test case to demonstrate the issue. It should draw a white square on a blue background, but on Linux draws just the horizontal lines.

On 2017-08-11 19:05:09 +0000, Sam Lantinga wrote:

More end of line drawing issues with various drivers...

On 2017-10-18 14:52:30 +0000, Sylvain wrote:

duplicate because the test case draw lines of 1 pixel

*** This bug has been marked as a duplicate of bug 3162 ***

On 2017-10-18 16:54:19 +0000, Richard Russell wrote:

I am sorry, but declaring this bug to be a duplicate of # 3162 because the Test Case only draws single pixels is ridiculous. The bug affects lines of arbitrary length, and it remains a serious problem for my application. Perhaps the Test Case was a poor choice - I wanted something that would be obvious - but the bug should be reopened (and fixed!) in my opinion.

On 2017-10-18 18:35:32 +0000, Sylvain wrote:

It doesn't mean it won't be fixed!
I meant by marking it as a duplicated, that it would be fixed in bug 3162, by the patch I submitted.
But more likely, it will be fixed if we switch to texture instead of points.

On 2017-10-18 21:15:55 +0000, Sam Lantinga wrote:

It's helpful to consolidate bugs for tracking purposes. Don't worry, we are aware of the issue and will be addressing it.

Thanks!

*** This bug has been marked as a duplicate of bug 3162 ***

On 2017-10-18 23:43:28 +0000, Richard Russell wrote:

This bug is specific to Linux/OpenGL and I have listed the code in sdl_render_gl.c which appears to be responsible (it deliberately draws the line differently when neither MACOSX nor WIN32 is defined). Bug # 3162 makes no reference to this code so I cannot see on what basis it has been concluded that it is the same problem.

However Bug # 3162 links to Bug # 2796 (in the context of it being "another problem") which indeed appears to be a duplicate of this one; it explicitly refers to the same piece of code in the same module, and proposes the same solution. I didn't find it in a search because it talks about 'dropping pixels' but not that they are endpoint pixels.

So please mark this as a duplicate of Bug # 2796, not Bug # 3162. I wonder why the trivial solution proposed in 2014 has not been adopted in any of the releases since.