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 3600 - SDL_RenderDrawLine end-point behavior broken on Linux
Summary: SDL_RenderDrawLine end-point behavior broken on Linux
Status: RESOLVED DUPLICATE of bug 3162
Alias: None
Product: SDL
Classification: Unclassified
Component: render (show other bugs)
Version: 2.0.5
Hardware: All Linux
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-05 10:38 UTC by Richard Russell
Modified: 2017-10-18 23:43 UTC (History)
1 user (show)

See Also:

Attachments
Test case to demonstrate end-point behavior on Linux (1.93 KB, text/x-csrc)
2017-03-05 10:38 UTC, Richard Russell 		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 Richard Russell 2017-03-05 10:38:06 UTC 
Created attachment 2702 [details]
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.
Comment 1 Sam Lantinga 2017-08-11 19:05:09 UTC 
More end of line drawing issues with various drivers...
Comment 2 Sylvain 2017-10-18 14:52:30 UTC 
duplicate because the test case draw lines of 1 pixel

*** This bug has been marked as a duplicate of bug 3162 ***
Comment 3 Richard Russell 2017-10-18 16:54:19 UTC 
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.
Comment 4 Sylvain 2017-10-18 18:35:32 UTC 
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.
Comment 5 Sam Lantinga 2017-10-18 21:15:55 UTC 
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 ***
Comment 6 Richard Russell 2017-10-18 23:43:28 UTC 
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.