#2094 closed bug (fixed)
Bad rgb_color value on archiving BView
Reported by: | shinta | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Kits/Interface Kit | Version: | R1/pre-alpha1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | x86 |
Description
I archived and flattened a BView whose view color is R=0x01, G=0x02, B=0x03, A=0x00. When I viewed the flattened file with ViewIt, view color as int32 is 0x00030201 (order is ABGR).
In contrast, I got int32 value 0x01020300 (order is RGBA) in ZETA. Maybe, BeOS R5 is same with ZETA.
Haiku: hrev25000 (modified a bit for previous debugging) SHINTA
Attachments (3)
Change History (8)
by , 17 years ago
Attachment: | ArchivedInHaiku.rsrc added |
---|
comment:1 by , 17 years ago
I modified View.cpp as DigestCode2094.cpp and BView works well.
My concern is:
- Whether this code works well on PPC version of Haiku.
- Whether some function like swap_uint32() already exists.
by , 17 years ago
Attachment: | DigestCode2094.cpp added |
---|
comment:2 by , 17 years ago
Looks good, thanks!, I would just merge swap_uint32() and get_uint32_color() into a single function.
comment:3 by , 17 years ago
Status: | new → assigned |
---|
comment:4 by , 17 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Fixed in hrev25031. On second thought, your swap_uint32() function was misleading, as we actually need to have the int32 in host endian before passing it to AddInt32() - as the BMessage takes care about endian already.
Archived BView in Haiku.