How are graphics / drawing methods made? - graphics

Question

One thing I've noticed about programming is that whenever there's a method that draws individual pixels or gets data from individual pixels, it's always much slower than methods for drawing primitives or pre-made graphics. I was just wondering why that is. Wouldn't making those methods require (at some point) the use of a single-pixel drawing method? And if there's a faster way to do it, why wouldn't they make the single-pixel method do it that way as well?

Answer 1

Some thoughts:
Many modern computing environments include hardware acceleration for drawing graphics primitives. Instead of having the CPU access the video memory one pixel at a time, graphics acceleration hardware touches the video memory equivalent of multiple pixels at once. Drawing primitives can take advantage of such acceleration in ways that software pixel operations cannot. http://en.wikipedia.org/wiki/Hardware_acceleration has some useful pointers.
Even drawing primitives that run in software are highly optimized, often in ways that aren't (easily) accessible from higher level languages. For example, SIMD instructions in modern CPU's allow touching multiple pixel locations at once.
Finally, an interpreted language may introduce significant pixel-to-pixel delays, compared to a compiled language. This depends on the programming language you experimented with most.

Answer 2

There is overhead in GetPixel/SetPixel operations that can usually be optimized away when drawing a primitive that touches many adjacent pixels.
Consider how GetPixel and SetPixel must be implemented:
Determine if each coordinate is in bounds.
Compute the location in memory of that pixel.
Depending on the pixel format, isolating the data for that pixel might involve unpacking.
Now consider something like an axis-aligned rectangle primitive. The naive way to implement it would be a double loop over x and y and calling SetPixel:
void DrawRect(RGB color, int left, int top, int right, int bottom) {
for (int y = top; y < bottom; ++y) {
for (int x = left; x < right; ++x) {
SetPixel(x, y, color);
}
}
}
SetPixel is going to check that both coordinates are in bounds for every call, which is wasteful. If the y coordinate was valid for the previous pixel in the same row, then it's still going to be valid for the next one.
Additionally, in most raster formats, most of the pixels you set will be adjacent in memory, so a general purpose formula (even something simple like address = base + (y * stride) + x) is more calculation than just incrementing the last address for the next pixel on the same row.
This illustrates how many (most?) primitives can be drawn with far less bounds checking and calculation than a naive implementation using SetPixel. Primitive drawing operations tend to be optimized because they are so common.
On a modern machine, there's even more opportunity for optimization. Some primitives might actually be drawn by the GPU rather than the CPU. This is significant because the GPU has direct access to the video memory. The CPU typically has indirect access to the video memory, and pixel access would have to be shuttled back and forth across the graphics bus. Some graphics busses are very fast, but usually not as fast as accessing local memory. Sending a single draw-primitive command, which is only a few bytes, across the bus to the GPU is going to be a lot faster than sending many set-pixel commands.
Furthermore, GPUs are designed to do this kind of work in parallel. They generally have many simple cores that can work at the same time. So, if it's drawing a rectangle, the GPU might (for example) distribute each scanline to a separate core, and the entire rectangle will be drawn as fast as a single core can draw a single horizontal line.