I havent tested GF or pdp, but I have dont some testing between
Jitter 1.2.3, 1.5, and Gem 0.9.
Gem makes Jitter 1.2.3 its bitch for doing any kind of openGL work,
or texturing to the screen as far as raw framerates go, Jitter 1.5 is
a huge improvement over 1.2.3, but Gem still edges out in terms of
raw OpenGL capability (esp jitter 1.5 now has YUV support, but not
all 'effects' modules properly support it. However, Jitter all
inclusive allows for much more flexibility in what/how etc gets drawn
(esp. with 1.5 with full shader support, etc). I know shader support
is in cvs, but ive yet to toy with it for GEM.
I might be persuaded to do a bake off on a group of patches. Would be
a good way to learn the best way to program for each env. efficiency
wise.
And yeah, Documentation and all that ;)
v a d e //
http://homepage.mac.com/doktorp/ doktorp@mac.com
On Nov 16, 2005, at 9:45 AM, james tittle wrote:
On Nov 15, 2005, at 4:04 PM, shreeswifty wrote:
It only seems to be with pdp_ieee1394, which seems to HOG the
whole cpu and is mysteriously missing from newer versions. The OpenGL seems
to be much faster in GEM though....there are technical reasons for all this:
- pdp runs in it's own thread, and the quicktime sequence grabber
Idle() needs more time than it's given in pdp_ieee1394_thread(), so
it winds up blocking or something...I've looked at this, but
haven't figured out a way to make it work...good news is that you
can go ahead and use pix_video in gem and pix_2pdp with very little
cost...
- pdp_ieee1394 is mac only, so yves doesn't need to distribute it
in his linux archive
- pdp by itself doesn't use opengl: that functionality comes
from 3dp...otoh, opengl is gem's bread and butter...
...personally, I've not crosstested to see how pd/gem/pdp/pidip/ gridflow fare against max/msp/jitter/nato, but I'd imagine that it
more than holds it's ground except in documentation ;-)l8r, james
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list