[PD] gem: resize a texture / buffering textures

[Thoralf Schulze]

hi chris,

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

1. draw some geos
2. take a snapshot, pix_buffer_write it to a buffer
3. 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