🚀 go-pugleaf

In article <1992Sep1.033025.7164@news.media.mit.edu> mike@media-lab.mit.edu writes:
>The problem is this: when you grab the frame, you get an
>image with representation NXCachedImageRep, which presumably
>somewhere has a pointer to the raw image in NeXTDimension memory.
>There are no methods to directly read this data, although you
>can draw it out to another view.  I tried compositing the
>NXCachedImageRep image into a newly allocated image with
>an NXBitmapImageRep (a TIFF), but the latter was converted
>to an NXCachedImageRep! ...
>What I would like to do is simply get my hands on the pixel array
>that underlies the NXCachedImageRep of a grabbed frame,
>without copying and converting the whole frame.

First or all, there's no way to get a pointer to the bits in the
frame buffer.

However, under 3.0 the process of reading images back from the
window server is efficient enough such that if you use NXBitmapImageRep's
initData:fromRect: method, you might get back what is essentially
a vm_copy() of the window's backing store. To process the data you need
to pay attention to the bitsPerPixel and bytesPerRow parameters of the
NXBitmapImageRep.

Clients of NXReadBitmap() and 2.0 apps do not get back unpacked data;
so for them the data might have to be packed after it's brought over
from the window server. However, even in that case the process of reading
images back is faster as the data is brought back out of line.

Now, on the NeXTdimension, the out of line data transfer always requires
a copy over the bus, so the gain isn't as great, and it's not as if
you are simply getting a pointer to the image data.

Going back to your question... One easy way to get a NXBitmapImageRep 
from an NXImage is to lockFocus on the NXImage, and create a bitmap 
image rep with initData:fromRect:. This is not the ideal in all cases, 
but when the NXImage is basically a cached image, it works fine. And if
the situation is right, the initData:fromRect: will be very fast.

Ali, Ali_Ozer@NeXT.com