• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSBitmapImageRep and 0RGB data
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSBitmapImageRep and 0RGB data


  • Subject: Re: NSBitmapImageRep and 0RGB data
  • From: "John C. Randolph" <email@hidden>
  • Date: Mon, 1 Jul 2002 12:46:50 -0700

On Monday, July 1, 2002, at 12:22 PM, Chris Hanson wrote:

At 2:42 AM -0400 6/29/02, Cameron Hayne wrote:
NSBitmapImageRep has no provision for pixel data in 0RGB order, but this sounds like a perfect Altivec permute opportunity.

If the data looks like:
0RGB0RGB0RGB0RGB...
Just shift your pointer over by one byte and then it will look like:
RGB0RGB0RGB0RGB...
and you need only add in the extra 'A' byte at the end.

And go from a 4-byte aligned pointer to a 1-byte aligned pointer. I don't know if it's valid to pass unaligned data to NSBitmapImageRep, and even if it is, what the performance impact of all those unaligned accesses would be.

Without getting too technical, I'd just say that it would be sub-optimal ;-) (Not to mention the hazard of reading one more byte than was allocated for the pixel data..)

As John said, it's a perfect AltiVec permute opportunity.

vector unsigned long ff = (vector unsigned long) (0xFFFFFFFF,
0xFFFFFFFF,
0xFFFFFFFF,
0xFFFFFFFF);
vector unsigned char perm = (vector unsigned char) (01, 02, 03, 10,
05, 06, 07, 10,
09, 0A, 0B, 10,
0D, 0E, 0F, 10);
destPixels = vec_perm(sourcePixels, ff, perm);

This converts the four pixels in sourcePixels from 0RGB0RGB0RGB0RGB to RGBARGBARGBARGBA (where A is 0xFF).

In the non-AltiVec case, my code had been doing the equivalent of shifting each source pixel left by 8 and or'ing with 0x000000FF. I haven't actually tested the AltiVec code yet; I want to get more other functionality done before I really start optimizing for speed.

I think there's also format conversion support in QuickTime. I might look into that, because I'd expect it to be more optimized than something I write off the top of my head. I should also probably file an enhancement request against NSBitmapImageRep asking for support for any pixel format QuickTime supports...

Well, you can already bring in any *file* that QT supports. That doesn't carry through to pixel formats in memory though, and I don't expect that it will any time soon.

-jcr

John C. Randolph <email@hidden> (408) 974-8819
Sr. Cocoa Software Engineer,
Apple Worldwide Developer Relations
http://developer.apple.com/cocoa/index.html
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: NSBitmapImageRep and 0RGB data (From: Chris Hanson <email@hidden>)

  • Prev by Date: Re: NSBitmapImageRep and 0RGB data
  • Next by Date: Re: ARGH Re: Accessor method article preview
  • Previous by thread: Re: NSBitmapImageRep and 0RGB data
  • Next by thread: Re: ARGH Re: Accessor method article preview
  • Index(es):
    • Date
    • Thread