hi chris,
i think pix_snap2tex is really more appropriate for feedback. I'm not surewhat you plan to do with pix_buffer.
- draw some geos
- take a snapshot, pix_buffer_write it to a buffer
- during the next render cycle, pix_buffer_read it
and put it as a texture on a rectangle filling the gem win as the first thing 4. goto 1. :-)
we talked about using pix_snap2tex for this purpose already (and ruled out its usage pretty much): http://lists.puredata.info/pipermail/pd-list/2006-08/041727.html . if there is a way to do feedback with pix_snap2tex, i'd very interested to learn about it.
since both pix_buffer_read and pix_buffer_write
are
tremendous resource hogs,
In what way? pix_buffer can take a lot of RAM but should take little CPU time. The problem with audio and midi is that GEM will tie up Pd for longer than the time slicing for audio or data. However,
is there any way of untying pd and gem? threads come to my mind, if one is blessed with recent hardware, these could even run on different cores ... and with a 4-core-amd, even tcl/tk could run on its own core. pretty close to paradise :-)
400x300 is not a huge amount of pixels to move to the GPU. What sort of hardware is this happening with?
p4 (northwood)@2.53 ghz, geforce 5700u (with the mainboard supporting only 4xagp). running the attached patch (hope it doesn't get you in a bad condition yet again, please consider it as a proof of concept) causes the following cpu usage here (pd 0.39.2, latest gem cvs on win 2k; couldn't test in linux yet): at 320x240, 20fps: 20% 400x300, 20fps: ~28% 400x300, 30fps (does look a lot better than 20): ~40% from here on, the patch cannot be controlled with an usb midi controller in a meaningful way any more ... 640x480, 20fps: ~48% 800x600, 20fps: ~60%
interestingly enough, when using the m$ sound mapper istead of creative asio as pd's sound drivers, midi is fine even at 800x600. but the latencies are way beyond realtime.
(www.avisynth.org ).
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
yeah, those peoples first concern is quality :-) however, decoding a movie might is probably more expensive than decently resizing it afterwards. and doing so is supposed to save some processing time in the following pix_- objects ... i usually use lanczos4resize in my avs-scripts, which i remember as being quite fast. a (simple) bicubic resizer should be even faster.
with kind regards, thoralf.
The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html