Ticket #2094 (closed bug: fixed)

Opened 2 years ago

Last modified 2 years ago

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: Platform: x86
Blocking:

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: r25000 (modified a bit for previous debugging)  SHINTA

Attachments

ArchivedInHaiku.rsrc Download (2.1 KB) - added by shinta 2 years ago.
Archived BView in Haiku.
ArchivedInZETA.rsrc Download (2.3 KB) - added by shinta 2 years ago.
Archived BView in ZETA.
DigestCode2094.cpp Download (0.9 KB) - added by shinta 2 years ago.

Change History

Changed 2 years ago by shinta

Archived BView in Haiku.

Changed 2 years ago by shinta

Archived BView in ZETA.

Changed 2 years ago by shinta

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.

Changed 2 years ago by shinta

Changed 2 years ago by axeld

Looks good, thanks!, I would just merge swap_uint32() and get_uint32_color() into a single function.

Changed 2 years ago by axeld

  • status changed from new to assigned

Changed 2 years ago by axeld

  • status changed from assigned to closed
  • resolution set to fixed

Fixed in r25031. 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.

Changed 2 years ago by shinta

Thank you for modifying my code!

Note: See TracTickets for help on using tickets.