Talk:Bresenham's line algorithm

message: I miss two things in this article:
* the applications of this algorithm. I understand what the algorithm could be used for, but I'm pretty sure not everybody will
* an explanation of how it works and/or comments in the code
I don't know the algorithm myself, so I'll leave it to somebody else. Jeronimo 14:36 Jul 25, 2002 (PDT)
:I agree and hope that more is contributed. I'll comment my code a little bit later and see what I can do for a small history section and applications section a bit later today. I'd add that it would be nice to see articles for other line algorithms. Rlee0001 15:20 Jul 25, 2002 (PDT)
: If you want comments, try .  (Disclaimer, this is my own code.)  Note that the article used a slope/intercept equation for the line, and therefore has some "fiddly" detail.  The example I point to uses homogenous coordinates, so has no special cases. It also has at the end a common variant that directly draws anti-aliased lines. This is the variant that puts out dots on a screen.  It also incorporates the change recommended by Tran Thong, to insure exactly the same dots independent of line direction that used to be needed for the "erase by drawing black in the reverse order" used in early graphics as part of dragging line segments around. Interesting how such history is being lost for something that used to be used a lot.  Floating point was expensive, integer cheaper, so the standard procedure used to be to convert the points to the final integer calcomp coordinates and do as my example did. I don't think I ever saw a production version using floating point. The article could also point out the uses of the algorithm in non-graphics contexts.  And people might be interested in the "restartable" variant that was used to make a exactly the same dots when putting a graphic out in strips as when done as a whole. Ahhh... history. Nahaj 23:33, 14 November 2005 (UTC)
thread_title: Untitled

message: Since the Bresenham algorithm is primarily applicable to raster devices, the initial use of it on Calcomp plotter devices (that can inherently draw straight lines by pen movements) is not clear.  Rendering of "dotted" lines is probably the way that the algorithm was used with plotters, but I'm not sure.  Can anyone provide the answer?  - Bevo 13:07, 25 Jul 2004 (UTC)
replies: text: It turns out that the early Calcomp plotters were "incremental" in nature, thus requiring an algorithm like Bresenham's. See http://www.pdp8.net/563/563.shtml Calcomp 563 Incremental Plotter Information - Bevo 20:52, 29 Jul 2004 (UTC)

text: And they could lose increments under a number of conditions. Hence the "trick" of many plot libraries of the time of drawing part of a registration symbol in some corner at the start, and the rest of it at the end of the plot.  If the symbol was correct you had some assurance that the plot was plotted normally, otherwise if the parts were offset, or garbled, there was an error of SOME sort. Nahaj 23:33, 14 November 2005 (UTC)
thread_title:  Calcomp plotter application 

message: X increases to the right, as is normal, but Y is increasing downwards rather than upwards.
I realise it just depends on whether the origin (0, 0) is in the top-left or bottom-left corner, but it does seem that this choice is causing confusion, hence the incorrect "This first version only handles lines that ascend to the right", shouldn't it be descend?
I'd suggest that +X == right, +Y == up will be more familar to the layman that comes from cartesian coordinates in maths at school without them having to mentally flip along the X axis.
-- Ralph Corderoy 11:36, 3 December 2006 (UTC)
replies: text: Postive y = down seems to be the dominant convention in computing. Plugwash 11:25, 4 December 2006 (UTC)

text: Just think of it as quadrant IV of a graph. Jamestheprogrammer 15:21, 10 March 2007 (UTC)

text: Plugwash is right, the Y axis increases downwards (in C++)  --Shreyasjoshis 05:28, 21 April 2007 (UTC)

text: This standard likely arose due to the fact that standard CRT monitors render the screen from top to bottom and so implementing a graphical mode with Y rising towards the top of the screen would require--at the simplest--making X rise towards the left, and reversing the data order somewhere before it gets fed out the VGA port. A solution with +X being right and +Y being up would require some more complex method which reverses the order of lines, but not the order of pixels.Upthorn 05:37, 14 May 2007 (UTC)

text: It's probably also due to the fact that text is written starting at the top left hand corner of the page, going downwards as it progresses.  For example consider how you initialise an array of memory in C.  The first location is initialised first and the next ones across/down the page.  If positive Y wasn't downwards everything would be upside down.  By the way, you can easily flip between the two formats by just by doing "plot( x, (YRES-1)-y )" instead of "plot( x ,y )" 77.103.105.67 (talk) 11:54, 6 May 2020 (UTC)
thread_title:  Why is Positive Y Downwards? 

message: in the line drawing algorithm article it is claimed that this avoids floating point arithmetic yet the code here clearly doesn't. Please clarify. Plugwash 21:44, 20 March 2006 (UTC)
replies: text: Ahh just noticed the last section "optimising", i think i'll clarify things a bit so others don't miss it though. Plugwash 22:19, 20 March 2006 (UTC)
thread_title:  Floating point 

message: For what it's worth, I converted the final optimized pseudo-code into a C++ routine.  Did a faithful line-by-line implementation, I believe.  Bottom line: it didn't work.  Some octants of the plane worked fine.  Others would only produce 45-degree lines.  Went back and checked and re-checked my implementation.  It was doing everything the pseudo-code said to do, and in the same order (as far as I could tell).
Went to a different website and converted their pseudo-code version into a C++ implementation.  It works perfectly.  Might want to double check this Wiki's pseudo-code to see if it really is correct.
:It should be noted that the supplied algorithm only works when (x1, y1) specifies the top left point of the line and (x2, y2) the bottom right. Reference implementation below should be a 1:1 port of the pseudo code (to C++). PrisonerOfPain 23:32, 20 September 2006 (UTC)
replies: text: The C code currently on the article didn't work for me either, with the same problem you described. Why does the code below say it's incorrect? Does it not work either? Dood77 (talk) 18:12, 29 November 2007 (UTC)
thread_title:  Final Optimized Code 

message: I felt so free to add this chapter as a direct translation from the german version, where I also contributed this and some other parts. As my mother tongue is not English, someone might want to go over the wording of this new chapter and turn it more into real English... Also the initial description of the algorithm and the illustration differs severely in the german version, perhaps we can throw it all together and extract the best of both. de:PeterFrankfurt, 4 February 2007 —The preceding unsigned comment was added by 84.177.118.110 (talk) 15:08, 4 February 2007 (UTC)
replies: text: Well, this is only a problem for (maximum) 4 pixels in the whole circle (in 50 % of the cases 0 pixels), I for my person can live with this redundancy. --PeterFrankfurt 17:19, 10 March 2007 (UTC)
thread_title:  Circle Variant 

message: Most of this article is NOT about Bresenham's algorithm, but about various other DDA algorithms that are variations of it, or generalizations of it. I would recommend that this article be renamed DDA or Digital Differential Analyzers, and it be made clear which algorithms are actually Bresenhams (mostly just the first bit), and which, such as the midpoint generalization are due to later computer scientists.
For example the "Different Approach" is the midpoint DDA algorithm and is due to 
Pitteway: Pitteway, M.L.V., "Algorithm for Drawing Ellipses or Hyperbolae with a Digital Plotter", Computer J., 10(3) November 1967, pp 282-289
Van Aken (Van Aken, J.R., "An Efficient Ellipse Drawing Algorithm", CG&A, 4(9), September 1984, pp 24-35) showed that the midpoint algorithm produces the same output as Bresenham's.
Swestrup 17:59, 28 February 2007 (UTC)
replies: text: Ok, so I changed this and tried to attribute these parts more correctly. Yet I think we should leave this together under the label Bresenham, because this is what will be searched for by interested people. --PeterFrankfurt 14:03, 2 March 2007 (UTC)
replies: text: I think the original point still stands. The title of the article is "Bresenham's line algorithm". I don't see a problem with including the other content on the work by Pitteway and Van Aken in some other, more general article on line and circle drawing (or, given the level of technical detail, perhaps in their own articles). Those articles could certainly be linked from here. But I don't think that stuff belongs in this article. "Interested people" will still be able to find the other algorithms via the in-article wikilinks, while this article will regain some focus. --Allan McInnes (talk) 06:36, 18 May 2007 (UTC)
thread_title:  Not about Bresenham's Algorithm 

message: UNderstanding the Computation of the decision parameter that the mid point circle, ellipse algorithms use is very important to grasp the algorithm fully, and for completeness.-Weedrat 16:23, 29 April 2007 (UTC)
thread_title:  Computing the decision parameter 

message: Having implemented the circle variant in AVR assembler, using the BASIC example as a starting point I find two interesting things (both proven by running the example code in BBC Basic for windows as well):
First, calculating Y^2 and X^2 is totally redundant; OK it shows how the calculated values relate back to Pythagorus' theorem, but they are a waste of processor time if people understand this as a real-world example.
Second, in porting to a non-floating point environment I calculated Y-end by multiplying r by root-2 * 65536, then discarding the lowest two bytes of the result. Fair enough, but the end point of the octant is the point where increasing y and decreasing x become equal. yend need not be calculated and the while-wend loop test can be y<=x. This avoids any floating-point calculation at all, indeed it avoids the calculation of a surplus value altogether.
I can't see any issues with this any comments? (Other than my bad spelling, now corrected)
:You are completely right, the calculations of Y^2 and X^2 are unnecessary, and yend can be replaced by the test for y<=x. Let's see what optimizations will come next. Good point. --PeterFrankfurt 00:08, 9 May 2007 (UTC)
thread_title: Changed Circle Pseudo Basic example

message: The article assumes an inverted coördinate system, a line going slightly downward, and it says "(that is, the line has a slope greater than -1 and less than 0.)". These three assertions cannot all be true.
*If the first two are true, then the slope must be in <0, 1>
*If the first and last are ture, the line must go slightly upward.
*If the last two are true, the coördinate system must not be inverted.
Make up your mind and fix it. Cheers, Shinobu 15:56, 19 May 2007 (UTC)
replies: text: As of Apr 12, 2017 the slope is still claimed to be negative when y1 > y0 (and x1>x0). This occurred in the 3rd paragraph of the Method section. The offending line was:"...(the line has a negative slope whose absolute value is less than 1)." I am correcting it. For writers who are unable to grasp the fact that increasing y as x increases always means the slope is POSITIVE (in this coordinate system this means as x increases to the right →, y increases downward ↓ ) then please refrain from editing it. Thanks98.21.215.86 (talk) 19:22, 12 April 2017 (UTC)
thread_title:  The slope of the line is wrong 

message: I'd like to note that these line drawing algorithms posted by PrisonerOfPain and the Bresenham's line algorithm discussed in the article will not even work for some lines going right down. Here is an example, line start at [1,1] and ends at [3, 25] the line is going right down(in the raster coordinate system), as you will see you'll loop only 2 times drawing only two pixs.
There should be another loop for drawing all the Y axis pixs or you might want to calculate the ratio of the dx/dy and take that into account when looping from x1 to x2. I'm in the middle of the exams right now so I'll through my line drawing algorithm a bit later.
Fomas 02:03, 24 May 2007 (UTC)
thread_title:  It won't even work for some lines going to the right down 

message: The following algorithm allows you to draw any straight line with any slope.
Note that it can be optimised by drawing pixels from both ends to the middle.
 Function drawLine(x1, y1, x2, y2)
    int dX = Abs(x2 - x1)
    int dY = Abs(y2 - y1)
    int x = x1
    int y = y1
 
    If (x1 > x2) Then offsetX = -1 Else offsetX = 1
    If (y1 > y2) Then offsetY = -1 Else offsetY = 1
 
    SetPixel(x,y)
 
    If (dX > dY) Then
        int error = dX / 2
 
        While (x != x2)
            error = error - dY
 
            If (error < 0)
                y = y + offsetY
                error = error + dX
            End If
 
            x = x + offsetX
 
            SetPixel(x,y)
        Wend
    Else
        int error = dY / 2
 
        While (y != y2)
            error = error - dX
 
            If (error < 0)
                x = x + offsetX
                error = error + dY
            End If
 
            y = y + offsetY
 
            SetPixel(x,y)
        Wend
    End IF
    End If
 End Function
Fomas 00:00, 26 May 2007 (UTC)
thread_title:  General Line drawing algorithm 

message: Is that discussion particularly relevant? I'd opt for deletion... semanticprecision 15:53, 6 July 2007 (UTC)
thread_title:  Sum of First n Odd Numbers 

message: This article is a mess now - We have two alternate descriptions of the same algorithm, a better approach would have been to instead  modify the original content to incorporate the new info. So now we have what basically is a content fork in the same page. I'm tempted to move the second description into a sandbox, so we can move the useful bits back into the article piece by piece. If no one objects, I'll most likely do this in a day or two. henrik•talk 11:28, 9 August 2007 (UTC)
thread_title:  Sorry state of article 

message: The C version of the algorithm is incorrect. It cannot draw lines where dy > dx. That's due to the simple fact that it's not including the "steep" variable which is used in the code above it. 91.89.169.47 (talk) 23:51, 10 January 2008 (UTC)
thread_title:  Errata 

message: Midpoint circle algorithm used to point to the "Circle variant" section in this article. The section was removed but I now moved that section to a new article. Not sure if that is the most used name for that algorithm so please make appropriate changes if you know better. Lakeworks (talk) 20:56, 12 January 2008 (UTC)
thread_title:  Moved the removed circle algorithm 

message: I was just doing a bit of revision for the Graphics module that I am doing and I stumbled on this and from what I know from lectures and so on this is NOT Bresenham Algorithm this is DDA. Bresenham is very subtly different it involves more pre-computation and no division in calculating decision parameter, therefore faster and better. Plus different calculations for decision parameter depending on value <0 or >0.
It is very misleading to call article something that it is not describing.  —Preceding unsigned comment added by Leshiy uk (talk • contribs) 21:38, 11 May 2008 (UTC)
replies: text: this is true, this is not Bressenham algorithm but "midpoint line" algorithm
93.184.73.10 (talk) 01:15, 24 May 2014 (UTC)
thread_title:  This Article is NOT Bresenham Algorithm 

message: Can I use the source code of C implementation given on the page in my MIT/X11 licensed software? 149.156.160.140 (talk) 08:04, 22 January 2009 (UTC)
thread_title: Source code license

message: The C99/C++ implementation does not draw a complete horizontal line.
When given as input (0,0), (2,0), it only plots pixels (0,0) and (1,0), and (2,0) remains blank.
Should this line:
for (int x = x0; x != x1; x += xstep) {
be changed for this one?
for (int x = x0; x <= x1; x += xstep) {
--155.210.155.136 (talk) 08:35, 17 July 2009 (UTC)
thread_title:  C99/C++ implementation cannot draw horizontal lines 

message: I've removed the implementation code from the article. We don't need this; the pseudocode is enough. As can be seen from the discussions above, the implementation code is error prone, and worse yet, it's original research. There's a related discussion at . The consensus was, that we don't really need implementation code, pseudocode is enough. Offliner (talk) 16:01, 9 August 2009 (UTC)
thread_title:  Source code removed 

message: The other implementation I saw is CRAZY slow so here is one I wrote, basically just converted the pseudo-code under the 'Optimization' header:
 	public static final void lineAlgorithm(int x0, int y0, int x1, int y1) { // Bresenham's line algorithm
 	boolean steep = Math.abs(y1 - y0) > Math.abs(x1 - x0);
 	if (steep) {
 		int tmp = x0;
 		x0 = y0;
 		y0 = tmp;
 		tmp = x1;
 		x1 = y1;
 		y1 = tmp;
 	}
 	if (x0 > x1) {
 		int tmp = x0;
 		x0 = x1;
 		x1 = tmp;
 		tmp = y0;
 		y0 = y1;
 		y1 = tmp;
 	}
 	int deltax = x1 - x0;
 	int deltay = Math.abs(y1 - y0);
 	int error = deltax / 2;
 	int ystep = -1;
 	int y = y0;
 	if (y0 < y1)
 		ystep = 1;
 	for (int x = x0; x <= x1; x++) {
 		error -= deltay;
 		if (error < 0) {
 			y += ystep;
 			error += deltax;
 		}
 	 }
     }
And is it just me or is the 'Simplification' version of the algorithm much slower than the initial optimized one?
24.193.99.41 (talk) 19:33, 8 August 2011 (UTC)
thread_title:  Java Implementation 

message: The "Derivation" part of the article doesn't really harmonize with the earlier segments. In the introduction of the algorithm it is assumed "that the pixel centers have integer coordinates." However, in the derivation part, the graphs seem to suggest that it is the top-left corner of the pixel that have integer coordinates. My mind is a hash salad right now after going through the algorithms, but it seems to me this ought to have some consequences. It's very confusing that the way the error accumulating variable is initialized is so different.
Also, the "Simplification" of the first algorithm to one that doesn't perform any swaps is impressive and I would really appreciate some pedagogic steps for its derivation. I think there could be some overall pedagogic value to this as well. Also, how does this relate to the other ones in terms of performance? I'm not sure simplification is the right word either.  — Preceding unsigned comment added by Arketyp (talk • contribs) 13:52, 14 March 2012 (UTC)
thread_title:  Clashing algorithms 

message: This is unreadable for any reader who actually cares to understand what is being said. 
The "Optimization" section states "This results in a divide inside the main loop, however...". What? What "divide" are you talking about? Where do you see a "divide" there? There's absolutely no meaningful explanation for why we switched from counting the errors from zero and up to counting it from deltax and down. Why, really?
The "Derivation" section begins with reinventing the canonical line equation in 2D. And it does it from scratch. Why??? Why not just use the Ax+By+C=0 as a commonly known basic fact?
The next "Algorithm" section is incomplete. It leads nowhere. The next "Algorithm with Integer Arithmetic" section is completely incoherent. It presents two formulas for the second point, but provides no explanation for what these equations are doing there. It speaks about the "difference D" but does not explain what that "difference D" is for the second point. What is D for the second point? What are those two formulas doing there?
50.242.89.251 (talk) 20:28, 26 April 2014 (UTC)
replies: text: I've removed the optimisation section. It was based on inaccurate and/or badly out of date information. It's no longer true that floating point numbers are slow, hasn't been for many years; on many modern CPUs and GPUs they're faster. And FP errors are not an issue. With just float (never mind double) you'd need to be drawing images millions if not billions of pixels wide for typical FP errors to be noticeable. Finally having multiple source samples is excessive; for the same reason I removed the following section which was just another optimisation based on it.--JohnBlackburnewordsdeeds 02:09, 21 September 2014 (UTC)
thread_title:  Lost of incoherent mumbo-jumbo 

message: :1. As I understand it the algorithm works by assuming the centers of pixels have integer coordinates - not the corners. In discord with this, some images and paragraphs give the idea that the corners of pixels have integer coordinates.
:2. In my opinion the animated image that is a screen capture of someone's unique implementation of Bresenham's line algorithm is unhelpful.
:3. The method to generalize the algorithm to all 8 octants can be simplified and presented more clearly.
72.229.111.192 (talk) 20:30, 24 May 2017 (UTC)
thread_title:  Some thoughts to improve the article quality