On 6/8/06, <b class="gmail_sendername">IOhannes m zmoelnig</b> <<a href="mailto:zmoelnig@iem.at" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">zmoelnig@iem.at</a>> wrote:<div><span class="gmail_quote">
</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
><br>> First, the csize selection does not work. On OSX it is fixed to 2 and<br>> neither 4, r, R, or RGBA changes it.<br><br>this is very weird.<br>the only reason i can imagine for this is that<br>imageStruct.setCsizeByFormat
(GL_RGBA) returns something very wrong (like<br>enforcing it to be ycbcr and ignoring the argument)...but i doubt it</blockquote><div><br>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. <br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">><br>> Second, after the shm buffer is set there is no way to change the
<br>> size. I get endless amounts of this:<br>><br>> pix_share_*: 2048x768x2: 3145728<br>> pix_share_*: someone was faster: only got 1572864 bytes instead of 3145728<br>> pix_share_*: shm:: id(131072) segsz(1572884) cpid (23205) mem(0x101F6000)
<br><br>you mean, you get this error message each render-cycle?<br>or do you repeatedly trigger a "set" message to [pix_share_write]?<br><br>><br>> Someone was faster? WTF? I get that even after deleting the
<br>> pix_share_write object and recreating it. Creating the object should<br>> set up whatever I tell it to set up.<br><br>the difference (iirc) between your original version and the current one<br>is, that both [pix_share_read] and [pix_share_write] set up the shared
<br>memory segment, whichever is faster (read: created earlier)<br>so "someone was faster" means, that another object (e.g.<br>[pix_share_read]) has already set up an shm-segment with the same id.<br>if the shm-segment is already there, then none of the objects try to
<br>resize it but instead use what is already there.<br><br>in order to free the shm-segment you will have to destroy ALL references<br>to it (read: all [pix_share_read] and [pix_share_write] objects<br>referencing the same segment)
</blockquote><div><br>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. <br><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">><br>> Finally, after setting up one shm buffer at an address I can no longer
<br>> create one at any other address. I get this message:<br>><br>> pix_share_*: 2048x768x2: 3145728<br>> error: pix_share_*: couldn't get shm_id: error 12<br>><br>> Again, I'm telling pix_share_write to create a shm buffer at a certain
<br>> address and of a certain size. Why would it refuse to do this?<br><br>i'll have a look at that (i cannot remember having that problem)<br><br>what comes to my mind is that the symbolic/numeric id exposed given is
<br>evaluated incorrectly.<br>could you please give the exact arguments of the [pix_share*] objects<br>you try to create?</blockquote><div><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">><br>> The code I checked in did not do this. I cannot figure out what the
<br>> intended function of some of the code is and do not know how to make<br>> changes other than reverting back to what I know works and continuing<br>> from that point.<br><br>it would be great if we could make the current version running on your
<br>system instead of reverting it to a version that is known to crash on<br>other systems. (in the end i hope it will work on all systems)</blockquote><div><br>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. <br>
<br>
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? <br>
<br>
cgc<br></div><br></div><br>