hello, on my computer, loading an images (with pix_image) use a separate threads, as i can se on the pd console. this is not the case on the HCS installer on osX. is it a osX limitiation, or a problem with Hans build? if so : what sould be made in order to include thread images loading?
thanks Cyrille
cyrille henry wrote:
hello, on my computer, loading an images (with pix_image) use a separate threads, as i can se on the pd console. this is not the case on the HCS installer on osX. is it a osX limitiation, or a problem with Hans build? if so : what sould be made in order to include thread images loading?
it is not an os-x limitation. however, threaded image loading is only done, when HAVE_PTHREADS is defined at compile time. the os-x installer uses the gem-binaries provided by jamie and/or chris, which are built via xcode. since xcode does not use configure, the changes are not automatically propagated to the build (e.g. someone would have to manually add HAVE_PTHREADS to the build-process).... ...thinking about this, i just noticed that Base/configDarwin.h.in is not prepared for the HAVE_PTHREADS yet, so even when using configure/make, you would not get threaded image loading on OSX.
i'll change this asap.
in the meantime, you would have to compile Gem yourself, after adding "#define HAVE_PTHREADS" to Base/configDarwin.h.
mfg.asdr IOhannes
On 10/24/06, IOhannes m zmoelnig zmoelnig@iem.at wrote:
i'll change this asap.
in the meantime, you would have to compile Gem yourself, after adding "#define HAVE_PTHREADS" to Base/configDarwin.h.
Don't do that. Quicktime is not always thread safe!
Many codecs and components are multi-threaded so Quicktime on OSX will use multiple CPUs when it can.
DirectShow does similar on Windows.
chris clepper a écrit :
On 10/24/06, *IOhannes m zmoelnig* <zmoelnig@iem.at mailto:zmoelnig@iem.at> wrote:
i'll change this asap. in the meantime, you would have to compile Gem yourself, after adding "#define HAVE_PTHREADS" to Base/configDarwin.h.
Don't do that. Quicktime is not always thread safe!
Many codecs and components are multi-threaded so Quicktime on OSX will use multiple CPUs when it can.
DirectShow does similar on Windows.
ok. would it be possible to allow threads only to load images? playing movie during images load result in 1 or 2 frame lost on the movie...
cyrille
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On 10/24/06, cyrille henry cyrille.henry@la-kitchen.fr wrote:
would it be possible to allow threads only to load images? playing movie during images load result in 1 or 2 frame lost on the movie...
As I understand the Quicktime documentation loading the file has to happen on the main thread, which would not solve the problem. Only after the file is opened and movie in memory can it be moved to another thread. We could add threading to everything else (including the OpenGL drawing) but that would require pretty extensive changes.
You could load all of your image files into a Quicktime movie and change the frames of the movie to get the next image.
chris clepper a écrit :
On 10/24/06, cyrille henry cyrille.henry@la-kitchen.fr wrote:
would it be possible to allow threads only to load images? playing movie during images load result in 1 or 2 frame lost on the movie...
As I understand the Quicktime documentation loading the file has to happen on the main thread, which would not solve the problem. Only after the file is opened and movie in memory can it be moved to another thread. We could add threading to everything else (including the OpenGL drawing) but that would require pretty extensive changes.
You could load all of your image files into a Quicktime movie and change the frames of the movie to get the next image.
yes, that was plan B. but it's always hard to explain why a patch work's better on my laptop than on a 6 months old G5.
thanks Cyrille
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On 10/24/06, cyrille henry cyrille.henry@la-kitchen.fr wrote:
but it's always hard to explain why a patch work's better on my laptop than on a 6 months old G5.
Use the laptop if it works better.
i nead my laptop! i made the patch, it will be used by someone else. i know i should have used the G5 to program this patch, but for few reason i prefered using my laptop.
cyrille
chris clepper a écrit :
On 10/24/06, *cyrille henry* <cyrille.henry@la-kitchen.fr mailto:cyrille.henry@la-kitchen.fr> wrote:
but it's always hard to explain why a patch work's better on my laptop than on a 6 months old G5.
Use the laptop if it works better.
On Tue, 24 Oct 2006, cyrille henry wrote:
yes, that was plan B. but it's always hard to explain why a patch work's better on my laptop than on a 6 months old G5.
Repartition the mac and install Ubuntu. That's what we did with 10 eMac computers last month, at Vidéographe, an artist-run centre in Montréal, QC.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard a écrit :
On Tue, 24 Oct 2006, cyrille henry wrote:
yes, that was plan B. but it's always hard to explain why a patch work's better on my laptop than on a 6 months old G5.
Repartition the mac and install Ubuntu. That's what we did with 10 eMac computers last month, at Vidéographe, an artist-run centre in Montréal, QC.
if i was asked, i whould i bought a pc, and install only ubuntu. but that was not an option. c
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev