I am trying to plan a graphics processor project that will only render lines. It will use the bresenhmam's line algorithm. After reading on the algorithm, it makes sense how it works to calculate locations of pixel that make up a line. What is not clear is how will this be output to a screen. Perhaps, the data will likely be stored into an external memory, but the obvious way to do so appears highly inefficient.
Assume I have 10 lines. I calculate the pixel values that make each of these lines, do I store these pixels into some internal FIFO for "dispatch"? Then another part of the design reads the pixel values to be "dispatched", calculates what location to store them in memory and writes them to memory. This has to do be done for each line meaning that a memory location may be read and written multiple times for a single frame if multiple lines pass through nearby each other. Is this correct? If so, then as the number of lines to draw increases, it will be harder to write full frame to memory by rendering all lines before the next frame has to read out since frame rate for video display is fixed.
This means there is no way to go from top left screen pixel to bottom right and find out if a given pixel is part of a line. I can't find a simple explaination for how to implement frame buffer for this type of system.
Best Answer
As you work out the pixels in each line you would calculate the bits in the frame buffer to set for that pixel. This would depend on the frame buffer organisation and number of bits per pixel. As you suggest drawing 10 overlapping lines means the same address is accessed multiple times, and again as the number of lines increases then you may not be able to draw all the lines before the frame scan.
This does not affect the drawing process though and you don't need to complete the rendering process before the frame is sent to the screen but it will result in flickering. In fact you will get flickering and this is where a second buffer would be used.
Image you have draw a complicated shape on the screen which needs to be rotated by 5 degrees. The display is sent the information from buffer 1. You calculate the new lines and write to buffer 2 while continuing to show bufer 1. Once complete you then wait for the last line to be displayed from the current buffer1 and switch the display logic so on the next scan it displays buffer2. All further writes are then to Buffer 1 until ready to switch back.
This is why on typical games benchmarks you may see frame rates drop to 12fps in complicated scenes. Not becauses the display drops from 60fps but because the same frame is displayed 5 times before the new frame is ready to be drawn.