I am receiving a large structure through a shared memory system that has lots of different data in it. One thing I need to do is to pull some pictures out of it and turn them back into pictures. I can get the pictures size from other data in the structure and I can even create a sub-memory block out of it by messing around with some pointers in temporary memory blocks so that I now have a memory block that starts at the point that the image data starts.
Unfortunately thats where it all falls apart. I cant pass that data into anything without copying it to another memory block first. If I try to pass the memory block which is contained within the full shared memory allocations block to any from data or even MBS loaders it fails to do anything. If I copy the bits to a new memory block then it works fine. There are 2 things different about the internal memory block and the new one. One is that its inside a shared memory block and perhaps these things just cant work on shared memory? The other is that these memory blocks report their size as unknown. Since I cant do anything about the first one I decided to try to tackle the second. I KNOW what the size of the memory block I create with the image data should be, but I dont see a way to tell the memory block what it is. If I try to adjust the size property of the memory block it re-allocates it or does something to move it and then there is no more data in it even as it shows the right size. So I can have the size, or I can have the data, but I cant have both 
I am only futzing with this because these are multi-megs of data in places and it just seems stupid to have to copy them out of the shared memoryblock in to a local one when Im just going to copy them again into a picture. I want to turn them into pictures directly from the shared memory buffer!
If I do a stringvalue conversion to get the data out of the shared structure and place it into another memory block with a known size then everything works great.
Is there any way to tell a memory block with an unknown size what its size actually is? Or can anyone think of another way to do this without leaving multiple copies of the data in memory for no good reason? Thanks.
years ago we had no Ptr data type. So we used MemoryBocks for Ptr with unknown size (-1).
From time to time we still see one of those.
when size is indicated as -1, you should know it and use code to copy data as needed.
These are memory blocks Im getting from a FileMappingViewMBS object They claim to be -1 in size. Ive been experimenting with many ways to get pictures between the apps for processing. In this case I was converting an NSIMageMBS to a compressed TIFF file and putting it into the shared memory. This comes across to the other side just fine, but if I pass that memory block, even if its loaded from a FileMappingViewMBS where the size of the view has been set specifically, to the memory block constructor of the NSImageMBS( data) the NSIMage has a 0 handle and no picture.
If I use copyBits or just use a stringValue to get the data out of the shared memory block and place it into a temporary one and pass that to the constructor it all works fine.
The smallest of the images Ill be moving will be around 800k if I used a compressed tiff format and it seems silly to have to copy them for each frame I process when the data is right there.
If you had to guess do you think the problem is that its a block of shared memory? or that the memory block doesnt know its size that is causing that to fail?
the plugin could better give you a Ptr.
There is no way for the plugin to give memoryblock for existing memory and a size.
If I give size, I have to make a copy.
If I understand it correctly (and forgive me if I don’t), but I’m pretty sure you can create a NSImage from a data pointer, so in that case, you pass to it the PTR for the image data location, which may not be the memoryblock that you have back.
Okay, so I was wrong, it’s a CGImage you can create from RAW data, for an NSImage, you need to wrap it in a NSData object (which means you need to know the length)… If you really want a NSImage, you can create a CGImage and then create a NSBitmapImageRep with it and inject that into a NSImage.
I dont care if its an NSImage or CGImage Im going to be converting it immediately back to a xojo picture in any case so that I can use it normally within the program. I do know the size so I will experiment with the CGImage conversion, thank you!
I might be able to copy the CGImageRef from the image in the server into the shared space and create a CGImage from it in the client by recreating the handle. Ive never needed to create a new handle inside of a xojo app so that could be interesting, but heres a path to sorting it out.
I assume that just copying the data around a few times, even if its large is still better than compressing and decompressing it into a smaller format for copying and it is lossless then if I dont do that which would be nice too.
It might even be possible, though its probably wishful thinking, that once the client CGImage is linked to the shared data that i wont have to re-create it with each update, it will just contain any new data that I put into there from the server since its pointing to the same location in memory. I dont know if it will handle size changes of the backing data though, so that could be interesting Im certainly learning a lot doing this even if Im not actually producing much code that works yet.
And no, I cant manipulate the handle from a CGImage any better than anything else. I thought that if it was a true handle then I could use getHandleSize on it to get the length and copy the memory from that start point for that length into the shared space and re-create the CGImage on the remote machine using the same opaque structure. But that didnt work at all. getHandleSize for that handle always returned 0 no matter what I tried to do to it.
It turns out that the copyRGBtoMemoryMBS and memoryRGBToPictureMBS (something like that ) are very fast about 1.5 milliseconds on this machine to move a 640x520 image into the memory buffer and about 2.5ms to re-create it on the other side. Im just going to use them and not muck about the lower down data structures. The data that they create is fairly large (widthheight3) for a non-alpha carrying pictures, but more testing shows me that my app only uses the memory for an image I actually put into the shared memory and not for the entirety of the shared memory I ask it to allocate to me which is nice. I can create a shared buffer that is large enough to hold the image and the data about it with plenty of overhead and not have to re-create the shared buffer with each frame I transfer that way.