Re: Rasterizing an NSString to a bitmap
Re: Rasterizing an NSString to a bitmap
- Subject: Re: Rasterizing an NSString to a bitmap
- From: John Stiles <email@hidden>
- Date: Thu, 10 Jun 2004 11:03:31 -0700
On Jun 10, 2004, at 9:55 AM, Marcel Weiher wrote:
You've gotten too tied up in implementation details.
Will windows always have backing stores? Almost certainly yes.
Will we developers be able to get access to that backing store? Sure,
many of us have already been down that road.
Actually, in NeXTstep days, we did *not* have access to the backing
store of a NSCachedImageRep. These were windows that lived inside the
WindowServer
I'm not talking about NSImages (or NSCachedImageReps)! I'm talking
about *windows*!
You have yourself convinced that NSImages and windows are related,
because in today's implementation they are intertwined. But I don't
think there is anything that says they have to be. We would be wise to
treat that as an implementation detail.
Will NSImages always be stored inside offscreen windows? I don't see
how that's a guarantee. I have yet to find any documentation
guaranteeing that an NSImage will have any particular representation,
or any example of code that gets pixels out of an NSImage without
using
NSReadPixel or relying on undocumented hacks like fudging the current
NSGraphicsContext.
Hold it. The -initWithFocusedViewRect: method is a documented and
reasonably efficient way to get rendered bitmap data. Even if it
isn't named brilliantly in relation to NSImage.
[image lockFocus];
[myObject draw];
bitmap = [[[NSBitmapImageRep alloc] initWithFocusedViewRect:myRect]
autorelease];
[image unlockFocus];
That's the canonical method of getting a bitmap of a rendered graphic
in Cocoa, as far as I am aware, and is independent of NSImage
implementation details. Another method is to get the
TIFFRepresentation, and then re-reading that, but that involves an
extra encoding/decoding step.
OK, this is true. That is faster method of getting a bitmap out of an
NSImage. Unfortunately, we end up with a bitmap with parameters that we
cannot specify, so it could be one of hundreds of different formats (if
you consider all the various permutations that could theoretically
arise). But fortunately, we can assume that the system won't give us
weird stuff like CMYK buffers back, since there are no window backing
stores in CMYK. Even then, there are a lot of potential bitmap buffers
that might come back to us, so it's still a pretty poor way to get bits
out. But you're right; it's much less awful than NSReadPixel.
I suppose if you could find a way to convert all the various
NSBitmapImageRep types into compatible QuickDraw formats, you could use
QTNewGWorldFromPtr->CopyBits to convert these pixels into the format of
your choosing. We would have to rely on Apple's good graces not to
change initWithFocusedViewRect to return more complicated buffer types.
Or maybe we could convince Apple to document all the buffer types that
initWithFocusedViewRect might return. That would be even better.
Should I file a documentation bug?
_______________________________________________
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.