Would anyone be able to briefly run me through what has changed about PixelARGB and the Colour class in the new version of JUCE?
In particular, there used to be a function getARGB() in PixelARGB, which was called by the function in the Colour class also called getARGB().
The Colour class getARBG() function now calls getInARGBMaskOrder() on a PixelARGB instance, and this produces different results. Can anyone explain the change and how it differs to the previous implementation?
Basically, Colour::getARGB() should always return a pixel in that order: ARGB. However, the internal format of how a pixel is stored is platform-dependent: it is ARGB on Windows and Mac, but ABGR on Android. So we want to be able to always return ARGB, but also to use the internal format (which may be ABGR) for internal colour computations like blend, tween etc. to make it fast. This is why we added that new function -- The Colour class getARBG() function now calls getInARGBMaskOrder(), ("in argb mask order" = in ARGB format) which internally calls either getNativeARGB() if you are not on Android, or performs the necessary conversion from ABGR to ARGB if you are on Android.
The old version did not have that distinction -- it was assuming that both the internal and the external pixel format was always ARGB, resulting in wrong colours on Android. So we rewrote that to fix it.
The only thing I'm confused about is why I'm seeing different results now - I am using OS X and if they were already ARGB on OS X, and the new function ensures they return ARGB, then why would it be different?
To give a little more detail, I have been storing colours as ValueTree properties by storing them as ints, casting the argb uint32 in a similar way to:
where settingsTree is a ValueTree. I don't know another way of doing this except casting to int...
I then later retrieve the colour similarly to:
int x = settingsTree.getProperty(MyClass::Ids::buttonColour);
uint32 colour = (uint32) x;
Colour buttonColour(colour);
This has always worked fine (though all the casting does smell bad - I didn't know how else to store the colour on the ValueTree and save to XML). The changes to the Colour and PixelARGB class have now made the retrieval of previously saved colours (using the old version of getARGB() ) not work, as things seem to be out of order.
So, in short, two questions...
1. Why would the changes have started producing a different result to what was happening before if I was using OS X and not Android?
2. Is there a better way to save colours on the ValueTree (and dump to XML) than my slightly icky casting to int? I can't convert from a uint32 to a var for storing on the ValueTree.
