[interfacekit] Interesting BBitmap info

I was just looking over the BBitmap headers and noticed a couple undocumented 
things which I toyed with a little and found quite interesting - 2 
undocumented (and very useful constructors).


enum {
        B_BITMAP_CLEAR_TO_WHITE                         = 0x00000001,
        B_BITMAP_ACCEPTS_VIEWS                          = 0x00000002,
        B_BITMAP_IS_AREA                                        = 0x00000004,
        B_BITMAP_IS_LOCKED                                      = 0x00000008 | 
B_BITMAP_IS_AREA,
        B_BITMAP_IS_CONTIGUOUS                          = 0x00000010 | 
B_BITMAP_IS_LOCKED,
        B_BITMAP_IS_OFFSCREEN                           = 0x00000020,
        B_BITMAP_WILL_OVERLAY                           = 0x00000040 | 
B_BITMAP_IS_OFFSCREEN,
        B_BITMAP_RESERVE_OVERLAY_CHANNEL        = 0x00000080
};

// This one we know and is documented
BBitmap(BRect bounds,color_space depth,bool accepts_views = false,bool 
need_contiguous = false);

// This one *certainly* beats using memcpy and allows for adding and removing
// the ability to add children from a BBitmap
BBitmap(const BBitmap* source,bool accepts_views = false,bool need_contiguous 
= false);

// The most intriguing and interesting - see below
BBitmap(BRect bounds,uint32 flags,color_space depth,int32 bytesPerRow=
B_ANY_BYTES_PER_ROW,screen_id screenID=B_MAIN_SCREEN_ID);


The last constructor allows you to set certain flags, such as whether the 
BBitmap has an area for a data buffer. Strangely, using the ACCEPTS_VIEWS 
flag in my short testing stint didn't seem to work, but I've been wrong 
before. Anyway, this goes rather nicely with the area_id Area() function. 
Nice to know for us graphics geeks, so I thought I'd pass it along. We should 
definitely (a)keep it in mind and (b)document it when we reimplement the 
BBitmap.

--DW

Other related posts: