Re: NSImageRep simple code
Re: NSImageRep simple code
- Subject: Re: NSImageRep simple code
- From: Ken Ferry <email@hidden>
- Date: Thu, 4 Mar 2010 11:40:51 -0800
This is true, and was true on 10.5 (and 10.4) as well though the timing has
changed some. The AppKit release notes have commentary on it.
This is a bit of an API problem. In order to draw a bitmap in Quartz, the
data must be packaged as a CGImage, which is immutable. This means the
client and AppKit need to agree on when it is legal for a client to be
looking at the bitmapData. -bitmapData by itself tells AppKit that the
client wants to look at (or mess with) the data, but there's way for the
client to communicate when it is done.
What actually happens is that repacking as a CGImage happens lazily. So if
you ask for bitmapData, modify the data, and draw the bitmap, then repacking
happens at that draw stage. Further attempts to directly access to the
memory after that point is bad - may crash, may not crash but also not
affect drawing.
The code wrote will work as is, because you haven't taken any action that
would cause the NSBitmapImageRep to pack things up as a CGImage. However, I
agree, to stay away from the edges of things I would set up the data before
making the bitmap, not after. Alternately it would be more explicit (and
thus safer) to call -bitmapData and modify the data returned, but that's
unnecessary here, you can just have the data set up right on input.
(If you're wondering about threading implications, see the AppKit release
notes.)
-Ken
On Thu, Mar 4, 2010 at 9:57 AM, John Horigan <email@hidden> wrote:
> It would be a good idea to modify the pixel buffer before calling
> initWithBitmapDataPlanes. NSBitmapImageRep makes no guarantee that changes
> to the data planes will be picked up by the NSBitmapImageRep after the call
> to initWithBitmapDataPlanes. It seems to work with OSX 10.5 and earlier, but
> Snow Leopard lazily copies the data planes to a CGImage. Once that copy
> happens, changes to pixel[] will have no affect on aSimpleBitmap.
>
> -- john
>
> On Mar 3, 2010, at 8:54 PM, Martin Beroiz wrote:
>
> > Hello everyone,
> >
> > I'm trying to understand how NSImageRep works, so I read the docs and
> came up with this simple code that seems to... do something.
> >
> > I'm confused about what's actually doing, I only see a big black block in
> my custom view.
> >
> > My intention is to make a 2x2 pixels image with different grayscale
> colors. For example one pixel black, the other white, etc, so I can see if
> it actually draws the array I'm passing in to NSImageRep.
> >
> > I'm guessing that the 2x2 pixel image will scale to fit the entire view
> so I will see the pixels as big squares in the view.
> >
> > Here's the relevant code:
> >
> > @implementation PixelsView
> >
> > - (id)initWithFrame:(NSRect)frame {
> > self = [super initWithFrame:frame];
> > if (self) {
> > pixels = (unsigned char *)malloc(4*sizeof(*pixels));
> > aSimpleBitmap = [[NSBitmapImageRep alloc]
> initWithBitmapDataPlanes:&pixels
> >
> pixelsWide:2
> >
> pixelsHigh:2
> >
> bitsPerSample:8
> >
> samplesPerPixel:1
> >
> hasAlpha:NO
> >
> isPlanar:NO
> >
> colorSpaceName:NSDeviceWhiteColorSpace
> >
> bytesPerRow:2
> >
> bitsPerPixel:8];
> > pixels[0] = 1;
> > pixels[1] = 0;
> > pixels[2] = 0;
> > pixels[3] = 0;
> >
> > }
> > return self;
> > }
> >
> > - (void)drawRect:(NSRect)dirtyRect {
> > NSRect bounds = [self bounds];
> > [NSGraphicsContext saveGraphicsState];
> > [aSimpleBitmap drawInRect:bounds];
> > [NSGraphicsContext restoreGraphicsState];
> > }
> > @end
> >
> > The docs say that NSDeviceWhiteColorSpace has pure white at 1.0, so I'm
> guessing that pixels[0] = 1 will set a white pixel, am I wrong?
> >
> > Xcode is not throwing any errors, but the view is not displaying what I
> expect. Since I don't fully understand bitmap images, is there anything
> obvious that I'm missing?
> >
> >
> >
> > Thanks in advance._______________________________________________
> >
> > Cocoa-dev mailing list (email@hidden)
> >
> > Please do not post admin requests or moderator comments to the list.
> > Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> >
> > Help/Unsubscribe/Update your Subscription:
> >
> > This email sent to email@hidden
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden