On 9/6/06, <b class="gmail_sendername">Thoralf Schulze</b> <<a href="mailto:thoralf_schulze@yahoo.de" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">thoralf_schulze@yahoo.de</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>no, my intention is still to create some<br>organic-looking video stuff by doing feedback: draw<br>something, take a snapshot of the render buffer and<br>use this as texture for a rectangle in the background<br>of the picture in the next render cycle. the pix_image
<br>in the attached patch was only there to simplify<br>things ...</blockquote><div><br>
i think pix_snap2tex is really more appropriate for feedback. I'm not surewhat you plan to do with pix_buffer.<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;">
since both pix_buffer_read and pix_buffer_write are<br>tremendous resource hogs, </blockquote><div><br>In what way? pix_buffer can take a lot of RAM but should take little CPU time.<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;">
i came up with the idea of
<br>resizing the texture and/or updating it only every nth<br>frame (is this possible at all?). pix_buffering a<br>texture larger than 400x300 pixels every render cycle<br>causes serious midi delays on my machine, which has
<br>only 4xagp (which is probably the bottleneck here).</blockquote><div><br>The problem with audio and midi is that GEM will tie up Pd for longer than the time slicing for audio or data. However, 400x300 is not a huge amount of pixels to move to the GPU. What sort of hardware is this happening with?
<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;">yeah, that would be really cool. maybe we could borrow<br>something form the avisynth people (
<a href="http://www.avisynth.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">www.avisynth.org
</a>).<br>there are quite a few resizing algorithms available in<br>that package, ranging from dumb linear resizing to<br>spline-based algorithms:<br><a href="http://www.avisynth.org/Resize" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://www.avisynth.org/Resize
</a></blockquote><div><br>A problem with a lot of the avisynth and vdub code is that it is really not designed for real time use at all. I forget which deinterlacer I was looking at but it took ages to do a 720x480 frame, which is fine for overnight batch encodes down to bitorrent size but pretty useless for real-time. It did look pretty nice though.
<br></div><br></div>cgc<br>