Why displays provide visual feedback in Raspberry Pi - Performance Analysis
When a display shows visual feedback, it updates pixels to reflect changes. We want to understand how the time to update grows as the amount of visual information changes.
How does the work needed to show feedback increase when the display changes more?
Analyze the time complexity of the following code snippet.
# Simulate updating a display buffer
for y in range(height):
for x in range(width):
display_buffer[y][x] = new_pixel_value(x, y)
update_display(display_buffer)
This code updates every pixel on the display to show new visual feedback.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Updating each pixel in the display buffer.
- How many times: Once for every pixel, so width x height times.
As the display size grows, the number of pixels to update grows too.
| Input Size (pixels) | Approx. Operations |
|---|---|
| 10 x 10 = 100 | 100 pixel updates |
| 100 x 100 = 10,000 | 10,000 pixel updates |
| 1000 x 1000 = 1,000,000 | 1,000,000 pixel updates |
Pattern observation: The work grows quickly as the total number of pixels increases, because each pixel needs updating.
Time Complexity: O(width x height)
This means the time to update the display grows directly with the number of pixels shown.
[X] Wrong: "Updating the display always takes the same time no matter how big it is."
[OK] Correct: Larger displays have more pixels, so updating all pixels takes more time.
Understanding how display updates scale helps you think about performance in real devices. It shows how work grows with screen size, a useful skill for many programming tasks.
"What if we only updated changed pixels instead of the whole display? How would the time complexity change?"
