Talk:Xiaolin Wu's line algorithm

message: "the nearly-horizontal case (Δx > Δy)"
makes more sense (to me) if it would read
"the nearly-horizontal case (Δx ≫ Δy)"
Am I missing something obvious here?
— Preceding unsigned comment added by 86.197.36.160 (talk) 21:48, 2006 April 7 (UTC)
Yes, the word "nearly" is a bit misleading. Δx > Δy is just the more-horizontal-than-not case,
in which one can iterate over x to draw all the points. 80.137.89.203 17:07, 1 August 2006 (UTC)
thread_title:  The nearly-horizontal case 

message: FYI, I used the pseudo-code posted on the wiki page as the basis for my own Wu line generator in C++ combined with SDL (Simple DirectMedia Layer).  It works very well, is very fast, and can be easily generalized to other octants in the plane.  Thanks a ton to the original poster.
— Preceding unsigned comment added by 199.120.31.18 (talk) 13:49, 2006 July 21 (UTC)
: I just implemented this in python and IMHO "ipart(x) == integer part of x" should be clarified to really mean floor(x),
: that is for negative numbers (like -2.5) it should still round down (to -3.0) instead of to the integer part (-2.0).
: Also i used "1.0-(intery-floor(intery))" to calculate the alpha (also because of negative numbers) 80.137.89.203 17:18, 1 August 2006 (UTC)
replies: text:  I agree with the statement made by User:80.137.89.203, Either ipart(x) is wrong or round(x) is. I corrected ipart(x) to floor it, now round(x) will return the correct answer for round(-5.2). Alternatively round should subtract a half when x is less than 0. I'm not completely sure which of those alternatives was intended. 2001:56A:700F:2500:18FF:17D4:9A71:BA39 (talk) 04:19, 15 June 2017 (UTC)
thread_title:  Posted Pseudo-Code Works 

message: This algorithm doesn't antialias diagonal lines (+45°, -45°, +135°, -135°) nor lines close to these angles aren't antialiased very visibly. Maybe this should be mentioned? 82.229.207.75 09:07, 15 December 2006 (UTC)
thread_title:  Diagonals 

message: Does the article link to the correct Xiaolin Wu? His website has no mention of anti-aliasing algorithm. --24.13.179.215 04:21, 24 June 2007 (UTC)
thread_title:  Author 

message: Shouldn't be this code inside the distinction between horizontal-ish and vertical-ish lines? The way it is implemented now can have the result that after swapping x and y,  x2 is again smaller than x1.
    if x2 < x1
        swap x1, x2
        swap y1, y2
    end if
194.78.35.195 (talk) 15:29, 19 February 2008 (UTC)
thread_title:  Code error? 

message: In the pseudo-code, the special-case to deal with dx == 0.0 is done after the division, which is a bit silly.  It should be something like
    gradient := 1.0
    if dx != 0.0 then
        gradient := dy / dx
    end if
ChrisDennis (talk) 17:03, 29 December 2021 (UTC)
thread_title:  Divide-by-zero trap 

message: This code does not seem to handle pixel intensity very well (if at all). It seems a very cheap substitution for real antialiasing line drawing algorithms. /Nurse Dragonbreath  —Preceding unsigned comment added by 85.19.218.76 (talk) 08:11, 6 September 2008 (UTC)
thread_title: And what about intensity?

message: Amir6723 (talk) 10:53, 4 August 2012 (UTC)
thread_title:  Using Wu's line algorithm in SDL 

message: While presented pseudo-code does the antialiasing part, it misses two features of original algorithm. First is utilising symmetry and drawing line from both ends to the middle thus doing only one calculation of intensity per two pixels advancement on x axis. Second is that it should actually be purely integer algorithm outside of initialization. Hence the claim in original paper that this algorithm is actually faster than Bresenham's. It says nothing about performance of either algorithm on today's hardware, but for history that's how it was: Wu's algorithm does half as much of additions, sign tests and comparisons as Bresenham's and about twice as much buffer writes. Loiten (talk) 08:09, 10 February 2014 (UTC)
thread_title:  Pseudo-code does not match Wu's Fast Antialiased Line Generator 

message: *It should discuss the colour space to be used. I've noticed that software using the wrong colour space draw angled lines a bit fatter for example.
*I think the algorithm as presented will not work correctly in places where the line is near the centre of a pixel, because then three pixels need to be plotted and this algorithm always plots only two. A common case where the error is very visible is that of a line angled at exactly 45°.  — Preceding unsigned comment added by 77.61.180.106 (talk) 20:17, 16 March 2022 (UTC)
thread_title:  Problems