Mark, I think we can agree that maintaining backwards compatibility is important, and that the methods as written are ambiguous. I'm on board with your compromise of adding additional, more clearly named methods. If Robert is on board, of course.
I guess we'll have to disagree on the endian issue :) IMO, since the value is not really an integer (it's really a packed byte array), there's no concept of a most or least significant byte; therefore endianness doesn't apply. GDI's COLORREF is a specific type with a known spec (red lives in bits 0-7, etc). If you byte-swap the value to put it on a big-endian machine, you break the spec. Same thing with our RGBA. Glenn Waldron : Pelican Mapping : +1.703.652.4791 On Thu, Sep 16, 2010 at 6:14 PM, Mark Sciabica <[email protected]> wrote: > Glenn, > > I do agree that your interpretation feels more natural to me, but I > definitely don't see it as the only possible interpretation. If you hand me > four bytes of RGBA color packed into a 32 bit value, I expect the first byte > to be the red channel. The question then arises, how does one number the > bytes? This is indisputably a question of endianness. > > As an example, the Microsoft Windows header file WinGDI.h defines a macro > to generate an integer value from RGB component byte values. This macro is > defined like this: > > #define RGB(r,g,b) > ((COLORREF)(((BYTE)(r)|((WORD)((BYTE)(g))<<8))|(((DWORD)(BYTE)(b))<<16))) > > The red component is in the least significant byte, just like the behavior > of asRGBA. I certainly wouldn't suggest doing things this way just because > Microsoft does, but I would claim that Windows' GDI API is prominent enough > to dash any claim that the opposite way of packing colors into an integer is > the only expected one. > > I do prefer the packing that you promote, I just don't think that's enough > reason to break compatibility since there are other reasonable > interpretations. > > Mark > > > On 9/16/2010 1:34 PM, Glenn Waldron wrote: > > Mark, > > I have to disagree with your initial statement. RGBA is a well-worn > specification for byte-encoded color. It implies a specific byte order. > Endianness is not relevant since it is not meant to be interpreted as an > integer. If you hand me 32 bits of data and tell me it's RGBA-encoded, I > expect to be able to do (data & 0xFF) and get the alpha component no matter > what platform I'm on. > > Glenn Waldron : Pelican Mapping : +1.703.652.4791 > > > On Thu, Sep 16, 2010 at 3:55 PM, Mark Sciabica <[email protected]>wrote: > >> Hi Glenn, >> >> I think what these functions *should* return can not be determined by >> the names of the functions. They return 32 bit integers and whether the >> low byte or the high byte corresponds to the first color channel named >> is not immediately obvious. Like you, my first guess would be that the >> high byte has the first named color channel so that asRGBA() would >> return 0xff for opaque black. As you have discovered, this is not what >> happens. >> >> However, on little-endian architectures (like the dominant x86) writing >> this 32 bit value to memory results in the bytes being ordered as in the >> function name. This is very useful, although not entirely portable. >> >> I would not recommend changing these functions' behaviors since that can >> easily break any existing code that uses them. New functions with more >> descriptive names could certainly be helpful. Documenting these >> functions is also a good idea so other users don't waste too much time >> wondering why their code does not behave as expected. >> >> Mark >> >> >> >> On 9/16/2010 11:53 AM, Glenn Waldron wrote: >> >>> Hi folks, >>> >>> Tthe methods Vec4f::asABGR() and asRGBA() appear to be reversed. (That >>> is, asABGR() returns RGBA and vice-versa.) Can someone lay another >>> pair of eyes on them and confirm this? >>> >>> >>> >>> >>> Glenn Waldron : Pelican Mapping : +1.703.652.4791 >>> >> >> This message and any attachments are solely for the intended recipient >> and may contain confidential or privileged information. If you are not the >> intended recipient, any disclosure, copying, use, or distribution of the >> information included in this message and any attachments is prohibited. If >> you have received this communication in error, please notify us by reply >> e-mail and immediately and permanently delete this message and any >> attachments. Thank you. >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
