PowerPC Pixel Order


#1

Hey Julian, i’m trying to track down a display issue with BubbleMessageComponent. It has something to do with transparent windows(as its the only component(that i’m using) that get’s affected). I am using the tip.

Here is the code

BubbleMessageComponent *msg=new BubbleMessageComponent(); msg->addToDesktop (0); msg->showAt(200,200, L"PowerPC PixelOrder test", 8000, true, true);

And screenshots…

IntelMac

Open App in Rosetta(problem is also on real PowerPC computers)

Result - PowerPC

I’ve tried tracking it down a little I think it could be in NSViewComponentPeer.mm - When juceImage.hasAlphaChannel you call swapRGBOrder with the note that our data is BGRA

but PixelFormats.h defines BIG_ENDIAN as ARGB

Hope that helps, and thanks so much as usual! Happy new Year to all…

Justin


#2

I no longer have a PPC machine to try this on, but is it just a case of doing this?

[code] void draw (const float x, const float y,
const RectangleList& clip,
const int originX, const int originY) const
{
#if JUCE_LITTLE_ENDIAN
// Our data is BGRA and the damned image rep only takes RGBA, so
// we need to byte-swap the active areas if there’s an alpha channel…
if (juceImage.hasAlphaChannel())
{
RectangleList::Iterator iter (clip);
while (iter.next())
{
const Rectangle* const r = iter.getRectangle();

            swapRGBOrder (r->getX() + originX,
                          r->getY() + originY,
                          r->getWidth(),
                          r->getHeight());
        }
    }

#endif

[/code]


#3

Building a universal app and running in Rosetta is good enough for most weird little endian tests…(get info on the file and check the rosetta box)

I’ll try your fix and see if it has any ill effect!

Tnx Jules


#4

Your suggestion didn’t work…a very PINK bubble message!

void swapRGBOrder (const int x, const int y, const int w, int h) const
    {
        jassert (Rectangle (0, 0, juceImage.getWidth(), juceImage.getHeight())
                 .contains (Rectangle (x, y, w, h)));

        uint8* start = imageData + x * pixelStride + y * lineStride;

        while (--h >= 0)
        {
            uint8* p = start;
            start += lineStride;

            for (int i = w; --i >= 0;)
            {
#if JUCE_BIG_ENDIAN
				jassert(pixelStride==4);
				const uint8 temp1 = p[3];
				const uint8 temp2 = p[1];
				p[3]=p[0]; 
				p[1]=p[2]; 
				p[2]=temp1;
				p[0]=temp2;
#else
                const uint8 temp = p[0];
                p[0] = p[2];
                p[2] = temp;
#endif
                p += pixelStride;
            }
        }
    }

#5

Right, so it needs quite a bit of juggling around! Thanks, I’ll try it in rosetta!


#6

Yea just to change ARGB to RGBA.

It is displaying properly, I just hope there aren’t any adverse affects somewhere else! (Hence the assert…seeing as this function is now SwapRGBA on PowerPC! A quick find in the trunk shows its currently only being using an Alpha images, so it should be ok, but it might be worth renaming the function!)


#7

It should be fine - that function’s only called when there’s an alpha channel.


#8

Bugger, you got that reply in while I was editing my comment!


#9

Note that it is possible to run any program in rosetta from the command line, and even to debug them in gdb :

(very convenient)


#10

useful link…tnx jpo