no, my intention is still to create some
organic-looking video stuff by doing feedback: draw
something, take a snapshot of the render buffer and
use this as texture for a rectangle in the background
of the picture in the next render cycle. the pix_image
in the attached patch was only there to simplify
things ...

i think pix_snap2tex is really more appropriate for feedback. I'm not surewhat you plan to do with pix_buffer.

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.

i came up with the idea of
resizing the texture and/or updating it only every nth
frame (is this possible at all?). pix_buffering a
texture larger than 400x300 pixels every render cycle
causes serious midi delays on my machine, which has
only 4xagp (which is probably the bottleneck here).

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?

yeah, that would be really cool. maybe we could borrow
something form the avisynth people ( www.avisynth.org ).
there are quite a few resizing algorithms available in
that package, ranging from dumb linear resizing to
spline-based algorithms:
http://www.avisynth.org/Resize

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.