Question

Q:

Setting pixels in the bitmap is sloooooowwww. How can you guys call yourselves the Media OS? Here's our function for the B_CMAP8 case:

void set_pixel8(BBitmap *bitmap, int x, int y, uchar8 color)
{
  bitmap->SetBits(&color, 1,
    y*bitmap->BytesPerRow()+x, B_CMAP8);
}

Answer 1

A:

SetBits() is a tool intended for importing rather than manipulating images. You were understandably bamboozled by its somewhat misleading name. Setting the color of a pixel is best accomplished with a cocktail composed of a healthy medley of Bits() and BytesPerRow() (mmm...tastier than nachos):

void set_pixel8(BBitmap *bitmap, int x, int y, uint8 color)
{
  *((uint8 *)bitmap->Bits() +
    y*bitmap->BytesPerRow() + x) = color;
}

In other words, think of a BBitmap as nothing more than a pixel buffer. Nothing requires you to draw pixels one at a time; you'll probably find it more convenient and more efficient to work directly with the pointer. For example, setting the buffer to white requires nothing more than:

memset(bitmap->Bits(), 0, bitmap->BitsLength());

Of course, you must always be aware of the color space of the BBitmap when directly altering its contents. SetBits() may prove itself useful by allowing you to normalize the color space to one understood by your rendering methods.

The other engineer on the project, the lovely Ms. Tanqueray, upon observing this interchange, gracefully retorts:

Answer 2

A:

If you're drawing polygons or ellipses or any other primitive found in BView, you always have the option of attaching a BView to the BBitmap and using our preexisting rendering methods. And, of course, you can always manhandle the bits directly even if a BView has been attached to the BBitmap.

After some experimentation, Ms. Tanqueray returns with further BBitmap comments:

Answer 3

A:

Surprisingly, the Be Book provides insight into this problem:

"If the color space mode is B_RGB32, the data should be triplets of three 8-bit components—red, green, and blue, in that order—without an alpha component. Although stored as 32-bit quantities with the components in BGRA order, the input data is only 24 bits in RGB order."

In other words, B_RGB32 indicates data in B_RGB24 order. As a further caution (some might call this a caveat or something), notice how the Be Book craftily avoids any mention of 15-bit, 16-bit, and big-endian color spaces. This is our subtle way of covering up SetBits()'s inability to interpret these spaces as sources or as destinations. Conversions involving these spaces will have to be performed by hand just as in the days of yore.

Issue 3-15, April 15, 1998

Be Engineering Insights: Booting Variations For PC And LILO

Case 1: BIOS -> LILO -> zbeos -> kernel

Case 2: BIOS -> LILO -> win95

Case 3: BIOS -> LILO -> LILO' -> linux

Case 4: BIOS -> LILO -> linux image

Case 5: BIOS -> LILO -> memtest86

Case 6: BIOS -> Partition Magic -> LILO -> zbeos -> kernel

Case 7: BIOS -> LILO -> LILO -> zbeos -> kernel

Case 8: BIOS -> zbeos -> kernel

Miscellany

Be Engineering Insights: Bugs and You

Welcome to Release 3 and Writing Better Bug Reports

Welcome to Kernel Debugging Land!

Requirements for serial debugging:

Serial Port Settings:

How to turn on serial output at boot time:

Dropping into the kernel debugger

How to drop in to the kernel debugger

What can you do in kernel debugging land?

What we at Be want to see from your serial debug output

Developers' Workshop: Square Peg, Round Hole

The Logic of Linux

Q:	Setting pixels in the bitmap is sloooooowwww. How can you guys call yourselves the Media OS? Here's our function for the B_CMAP8 case: void `set_pixel8`(`BBitmap` `bitmap`, int `x`, int `y`, uchar8 `color`) { `bitmap`->`SetBits`(&`color`, 1, `y``bitmap`->`BytesPerRow`()+`x`, `B_CMAP8`); }
A:	`SetBits()` is a tool intended for importing rather than manipulating images. You were understandably bamboozled by its somewhat misleading name. Setting the color of a pixel is best accomplished with a cocktail composed of a healthy medley of `Bits()` and `BytesPerRow()` (mmm...tastier than nachos): void `set_pixel8`(`BBitmap` `bitmap`, int `x`, int `y`, uint8 `color`) { ((uint8 )`bitmap`->`Bits`() + `y``bitmap`->`BytesPerRow`() + `x`) = `color`; } In other words, think of a `BBitmap` as nothing more than a pixel buffer. Nothing requires you to draw pixels one at a time; you'll probably find it more convenient and more efficient to work directly with the pointer. For example, setting the buffer to white requires nothing more than: `memset`(`bitmap`->`Bits`(), 0, `bitmap`->`BitsLength`()); Of course, you must always be aware of the color space of the BBitmap when directly altering its contents. `SetBits()` may prove itself useful by allowing you to normalize the color space to one understood by your rendering methods. The other engineer on the project, the lovely Ms. Tanqueray, upon observing this interchange, gracefully retorts:
Q:	You mean I have to draw everything myself as I did in the days of yore? What a crock! You should all be fired!
A:	If you're drawing polygons or ellipses or any other primitive found in `BView`, you always have the option of attaching a `BView` to the `BBitmap` and using our preexisting rendering methods. And, of course, you can always manhandle the bits directly even if a `BView` has been attached to the `BBitmap`. After some experimentation, Ms. Tanqueray returns with further BBitmap comments:
Q:	`SetBits()` is broken. This code is supposed to convert a `B_RGB32` bitmap into a `B_CMAP8`, but all I get is a garbled Technicolor mess! `BBitmap` `source32`(`bounds`, `B_RGB32`); `BBitmap` `dest8`(`bounds`, `B_CMAP8`); `dest8`->`SetBits`(`source32`->`Bits`(), `source32`->`BitsLength`()/4, 0, `B_RGB32`); Would you boys kindly explain what's going on?
A:	Surprisingly, the Be Book provides insight into this problem: "If the color space mode is `B_RGB32`, the data should be triplets of three 8-bit components—red, green, and blue, in that order—without an alpha component. Although stored as 32-bit quantities with the components in BGRA order, the input data is only 24 bits in RGB order." In other words, `B_RGB32` indicates data in `B_RGB24` order. As a further caution (some might call this a caveat or something), notice how the Be Book craftily avoids any mention of 15-bit, 16-bit, and big-endian color spaces. This is our subtle way of covering up `SetBits()`'s inability to interpret these spaces as sources or as destinations. Conversions involving these spaces will have to be performed by hand just as in the days of yore.