<p>The short answer is YES, you can not avoid doing a lot of bit manipulation if your format needs it.</p>

<p>Drawing a bitmap basically mean copy a pixel from a source to a destination and you have to do what it takes to do it. (Quoting Captain Obvious)</p>

<p>A longer answer is that if you write a software rasterizer, you can have some algorithm and trick to save you cpu time (by knowing which part you DO NOT NEED TO DRAW (transparency optimization), by having a pixel format of the source the same as the destination (directly or in a form of cache), optimally perform memcopy, etc... Basically consider the drawing loop of your rasterizer and see how you can restructure them to save CPU time. (ex : you could generate at runtime a piece of assembler code just specifically to print the letter A or have meta to your source bitmap info to tell you how to skip transparent area, etc..)
Each use case may have a different solution based on CPU instruction set, buffer format, the algorithm of your rendering primitive (rotating ? stretching bitmaps ? what kind of filtering ? etc...), CPU register and cache etc...</p>

<p>So yes anyway, it TOOK a lot of CPU cycle to write single pixel in the old days when weird encoding &amp; small memory were the norm. :-)
But it didn't forbid 16 / 32 bit machines with 8 MHZ CPU to do things like that : <a href="https://www.youtube.com/watch?v=GWwPJU6pp30" rel="nofollow">https://www.youtube.com/watch?v=GWwPJU6pp30</a> (And a big chunk of the CPU was used also for the music)</p>

<p>In the case of HW rendering, HW will perform the conversion from the source format to destination format and while it will not use much of the tricks available to SW rasterizer, its generic implementation in HW will most likely beat most of the SW implementation.</p>

CC BY-SA 3.0
2015-09-30T09:46:04.110Z
2015-09-30T10:08:55.720Z
2015-09-30T10:08:55.720Z
Romain Piquois
<p>Suppose we have a 64-bit word-addressable computer and we want to program it to output a 5x7 character stored as a binary image bitmap (such as the one below) to a memory-mapped display.</p>

<p><a href="https://i.sstatic.net/LfHfE.png" rel="noreferrer"><img src="https://i.sstatic.net/LfHfE.png" alt="enter image description here"></a> <a href="https://i.sstatic.net/jaPjM.png" rel="noreferrer"><img src="https://i.sstatic.net/jaPjM.png" alt="enter image description here"></a></p>

<p>Since we have 5 x 7 = 35 pixels per character, we could store a character using 35 bits in a single word. With the least significant bit starting on the left side of the word and with each pixel in the image being represented by the <em>n</em>th bit as shown above, the number "3" above would be stored in memory as: 01110100010000100110000011000101110, followed by 29 unused bits set to 0.</p>

<p>Is this how characters were/are stored in old/modern computers? Or do they use a single byte/word per pixel instead?</p>

<p>If they are stored in this manner, what would the routine in assembly/machine-code (using nothing more than elementary instructions such as bitwise, arithmetic and data transport operations from the computer's Instruction Set Architecture) used to convert this data into an image on the display look like? Would it be something like:</p>

<ol>
<li>Store the x and y display coordinate for the current pixel to be updated in a certain register.</li>
<li>Store the two chosen RGB values (in this case 0,255,0 for green and 0,0,0 for black) in two other separate registers.</li>
<li>Have two further registers act as counters initialized to 5 and 7 to keep track of the current row and column of the image being rendered.</li>
<li>Test if the column register is not 0. If it isn't, test if the LSB of the bitmap is set to 1, then AND the respective RGB value register with the x and y coordinate register depending on the result, then MOV that result to the display output register.</li>
<li>Decrement the row counter register by 1, test to see if it is 0. If it is, then set it back to 5 and increment the y coordinate by 1 and decrement the column counter by 1.</li>
<li>Shift the register holding the bitmap 1 bit to the left.</li>
<li>JMP to instruction 4.</li>
</ol>

<p>Is there a simpler or more efficient way to do this? It seems as though even something as simple as rendering a single small text character takes quite a large number of operations and would take around 200 CPU cycles.</p>

<p>Finally, are there any good books or resources on machine-level code for displaying images from scratch, because I haven't been able to find any as they either gloss over this particular subject or the code is written in a high level language or an assembler using macros, all of which are "cheating" and don't explain what is fundamentally going on at the lowest level.</p>

CC BY-SA 4.0
2022-03-24T04:08:28.937Z
I suppose you could look at all the excellent info about this in [HarfBuzz](https://harfbuzz.github.io/) which is a very widely used text shaping engine (turns text into bitmaps using fonts.)
Wyck
CC BY-SA 3.0
2015-09-27T19:08:12.660Z
The [Graphics Programming Black Book](http://www.jagregory.com/abrash-black-book/) is certainly a classic worth reading. A lot of oldschool black-magic in it ;)
glampert
CC BY-SA 3.0
2015-09-30T10:06:23.587Z
Yes, I second the book by Michael Abrash. It is a GREAT read. There are a lot more trick in the sleeve to what is written in this book but the philosophy behind it is important (even to this day !)
Romain Piquois
<rendering><2d><bitmap-graphics>
Fundamentally, how are 2D bitmaps rendered?
user1735
# Fundamentally, how are 2D bitmaps rendered?

(Asked by: username_0 on 2015-09-27)

Suppose we have a 64-bit word-addressable computer and we want to program it to output a 5x7 character stored as a binary image bitmap (such as the one below) to a memory-mapped display.

[![enter image description here](https://i.sstatic.net/LfHfE.png)](https://i.sstatic.net/LfHfE.png) [![enter image description here](https://i.sstatic.net/jaPjM.png)](https://i.sstatic.net/jaPjM.png)

Since we have 5 x 7 = 35 pixels per character, we could store a character using 35 bits in a single word. With the least significant bit starting on the left side of the word and with each pixel in the image being represented by the *n*th bit as shown above, the number "3" above would be stored in memory as: 01110100010000100110000011000101110, followed by 29 unused bits set to 0.

Is this how characters were/are stored in old/modern computers? Or do they use a single byte/word per pixel instead?

If they are stored in this manner, what would the routine in assembly/machine-code (using nothing more than elementary instructions such as bitwise, arithmetic and data transport operations from the computer's Instruction Set Architecture) used to convert this data into an image on the display look like? Would it be something like:

1. Store the x and y display coordinate for the current pixel to be updated in a certain register.
2. Store the two chosen RGB values (in this case 0,255,0 for green and 0,0,0 for black) in two other separate registers.
3. Have two further registers act as counters initialized to 5 and 7 to keep track of the current row and column of the image being rendered.
4. Test if the column register is not 0. If it isn't, test if the LSB of the bitmap is set to 1, then AND the respective RGB value register with the x and y coordinate register depending on the result, then MOV that result to the display output register.
5. Decrement the row counter register by 1, test to see if it is 0. If it is, then set it back to 5 and increment the y coordinate by 1 and decrement the column counter by 1.
6. Shift the register holding the bitmap 1 bit to the left.
7. JMP to instruction 4.

Is there a simpler or more efficient way to do this? It seems as though even something as simple as rendering a single small text character takes quite a large number of operations and would take around 200 CPU cycles.

Finally, are there any good books or resources on machine-level code for displaying images from scratch, because I haven't been able to find any as they either gloss over this particular subject or the code is written in a high level language or an assembler using macros, all of which are "cheating" and don't explain what is fundamentally going on at the lowest level.

**Tags:** rendering, 2d, bitmap-graphics

> **Comments:**
> **username_2**: The [Graphics Programming Black Book](http://www.jagregory.com/abrash-black-book/) is certainly a classic worth reading. A lot of oldschool black-magic in it ;)  
> **username_3**: Yes, I second the book by Michael Abrash. It is a GREAT read. There are a lot more trick in the sleeve to what is written in this book but the philosophy behind it is important (even to this day !)  
> **username_1**: I suppose you could look at all the excellent info about this in [HarfBuzz](https://harfbuzz.github.io/) which is a very widely used text shaping engine (turns text into bitmaps using fonts.)  

---

## 1 answers

### Answer by username_3 on 2015-09-30. Score: 1

The short answer is YES, you can not avoid doing a lot of bit manipulation if your format needs it.

Drawing a bitmap basically mean copy a pixel from a source to a destination and you have to do what it takes to do it. (Quoting Captain Obvious)

A longer answer is that if you write a software rasterizer, you can have some algorithm and trick to save you cpu time (by knowing which part you DO NOT NEED TO DRAW (transparency optimization), by having a pixel format of the source the same as the destination (directly or in a form of cache), optimally perform memcopy, etc... Basically consider the drawing loop of your rasterizer and see how you can restructure them to save CPU time. (ex : you could generate at runtime a piece of assembler code just specifically to print the letter A or have meta to your source bitmap info to tell you how to skip transparent area, etc..)
Each use case may have a different solution based on CPU instruction set, buffer format, the algorithm of your rendering primitive (rotating ? stretching bitmaps ? what kind of filtering ? etc...), CPU register and cache etc...

So yes anyway, it TOOK a lot of CPU cycle to write single pixel in the old days when weird encoding & small memory were the norm. :-)
But it didn't forbid 16 / 32 bit machines with 8 MHZ CPU to do things like that : <https://www.youtube.com/watch?v=GWwPJU6pp30> (And a big chunk of the CPU was used also for the music)

In the case of HW rendering, HW will perform the conversion from the source format to destination format and while it will not use much of the tricks available to SW rasterizer, its generic implementation in HW will most likely beat most of the SW implementation.


---

