[PD] gem: resize a texture / buffering textures

chris clepper cgclepper at gmail.com
Thu Sep 7 04:40:18 CEST 2006


On 9/6/06, Thoralf Schulze <thoralf_schulze at yahoo.de> wrote:
>
>
> 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.

cgc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20060906/056012f1/attachment.htm>


More information about the Pd-list mailing list