On 6/8/06, IOhannes m zmoelnig zmoelnig@iem.at wrote:
First, the csize selection does not work. On OSX it is fixed to 2 and neither 4, r, R, or RGBA changes it.
this is very weird. the only reason i can imagine for this is that imageStruct.setCsizeByFormat (GL_RGBA) returns something very wrong (like enforcing it to be ycbcr and ignoring the argument)...but i doubt it
I put a simple if statement in pix_share_write to replace the imageStruct call and it works fine. I think setCSizeByFormat() might not be working on the Mac. All those #ifdefs are hard to read! I will try to replace it with a single one for __APPLE__ and see if that helps.
Second, after the shm buffer is set there is no way to change the size. I get endless amounts of this:
pix_share_*: 2048x768x2: 3145728 pix_share_*: someone was faster: only got 1572864 bytes instead of
3145728
pix_share_*: shm:: id(131072) segsz(1572884) cpid (23205)
mem(0x101F6000)
you mean, you get this error message each render-cycle? or do you repeatedly trigger a "set" message to [pix_share_write]?
Someone was faster? WTF? I get that even after deleting the pix_share_write object and recreating it. Creating the object should set up whatever I tell it to set up.
the difference (iirc) between your original version and the current one is, that both [pix_share_read] and [pix_share_write] set up the shared memory segment, whichever is faster (read: created earlier) so "someone was faster" means, that another object (e.g. [pix_share_read]) has already set up an shm-segment with the same id. if the shm-segment is already there, then none of the objects try to resize it but instead use what is already there.
in order to free the shm-segment you will have to destroy ALL references to it (read: all [pix_share_read] and [pix_share_write] objects referencing the same segment)
This is the tricky part of these objects to deal with. You can either allow the user to whatever they want when setting up shm or put in a check to help keep them from doing something which might crash or become unusable. My original thinking was that anyone using these objects would have to really know what they are doing to set them up properly and to just let them do it.
The alternative idea to put checks in place to keep from crashing/etc should probably be even more complete. Rather than locking the shm per ID, pix_share_write should allow for resizing and the pix_share_read objects would have to be alerted to this change. In my initial testing (on OSX only) changing the size of the shm region for a single ID worked. If this is not the case on Linux then some other solution will have to be figured out.
Finally, after setting up one shm buffer at an address I can no longer create one at any other address. I get this message:
pix_share_*: 2048x768x2: 3145728 error: pix_share_*: couldn't get shm_id: error 12
Again, I'm telling pix_share_write to create a shm buffer at a certain address and of a certain size. Why would it refuse to do this?
i'll have a look at that (i cannot remember having that problem)
what comes to my mind is that the symbolic/numeric id exposed given is evaluated incorrectly. could you please give the exact arguments of the [pix_share*] objects you try to create?
This has to do with running out of shm memory. I was recreating the object with a new ID and values and it refused to go beyond a certain size. This leads me to think that created regions are not being freed since the 4MB allowance on OSX is used up by the first 1024x768 object.
The code I checked in did not do this. I cannot figure out what the intended function of some of the code is and do not know how to make changes other than reverting back to what I know works and continuing from that point.
it would be great if we could make the current version running on your system instead of reverting it to a version that is known to crash on other systems. (in the end i hope it will work on all systems)
I agree. I originally wrote the object from some code Chris Klippel used on Linux back in the old days of jMax video and it worked fine on OSX back then too. I could have made a mistake or the Linux spec could have changed since though.
I made some hacks since I need the code to work right then, so now it's time for real fixes. The first thing to figure out is how we want the object to behave in end use. Do we allow for any settings or do we confine the objects even further than they are now?
cgc