Hey Ben,
Are these dropped frames your seeing a result of rotating the object via numberbox/PD GUI or from another machine running over -nogui?
No, either. Rotating from metro. (See the patch) I have the same problem on my 667 PowerBook and my Linux pentium 2.6GHz.
I ask because the PD gui is known to have issues and it is easily possible that it is the number box causing this problem and not Gem. Try sending a signal from python over a local socket to pd/Gem running in -nogui.
It will probably work. The problem is the internal timing of PD/metro. It's CPU time base, not real time base. And without threads.
Does it do the same thing?
I'll have to test things on my new linux machine when I get it, but I hope what your saying is not evident. I don't see this happening on OSX. Do you have a test patch?
Here it is !
Disappointed B.
Disappointed E. too.
#N canvas 513 371 819 325 10; #X obj 187 150 gemhead; #X msg 71 9 destroy; #X obj 187 129 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 485 157 gemhead; #X obj 414 177 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X obj 485 264 pix_texture; #X obj 485 287 rectangle 5.333 4; #X msg 414 216 open $1; #X obj 414 195 openpanel; #X obj 485 137 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 485 240 pix_image; #X msg 503 186 open /home/etienne/Desktop/froime400.jpg; #X obj 187 198 rotateXYZ; #X obj 289 62 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0 1 ; #X obj 340 62 nbx 5 14 -1e+37 1e+37 0 0 empty empty empty 0 -6 0 10 -262144 -1 -1 0 256; #X obj 289 127 + 1; #X obj 289 105 f 1; #X obj 187 221 rectangle 2 2; #X obj 327 106 nbx 5 14 -1e+37 1e+37 0 0 empty empty empty 0 -6 0 10 -262144 -1 -1 0 256; #X msg 503 210 open /home/etienne/Desktop/thuangS.jpg; #X msg 16 9 create; #X msg 36 30 1; #X msg 98 31 0; #X msg 91 86 frame $1; #X obj 16 113 gemwin 30; #X msg 91 60 30; #X msg 125 60 60; #X obj 289 82 metro 33; #X obj 485 89 loadbang; #X msg 485 113 0; #X text 130 9 1 create the window; #X text 233 29 2 start rotating the square watch it rotating not smoothly! ; #X msg 254 151 0; #X obj 289 151 select 361; #X text 483 48 3 try to load some big textures (1024x1024) with the chain turn on or off watch the square stall; #X connect 0 0 12 0; #X connect 1 0 24 0; #X connect 2 0 0 0; #X connect 3 0 10 0; #X connect 4 0 8 0; #X connect 5 0 6 0; #X connect 7 0 10 0; #X connect 8 0 7 0; #X connect 9 0 3 0; #X connect 10 0 5 0; #X connect 11 0 10 0; #X connect 12 0 17 0; #X connect 13 0 27 0; #X connect 14 0 27 1; #X connect 15 0 33 0; #X connect 16 0 15 0; #X connect 18 0 15 1; #X connect 19 0 10 0; #X connect 20 0 24 0; #X connect 21 0 24 0; #X connect 22 0 24 0; #X connect 23 0 24 0; #X connect 25 0 23 0; #X connect 26 0 23 0; #X connect 27 0 16 0; #X connect 28 0 29 0; #X connect 29 0 9 0; #X connect 32 0 16 0; #X connect 33 0 32 0; #X connect 33 1 16 1; #X connect 33 1 12 3;
:(
Etienne Desautels wrote:
Hello,
On 05-06-05, at 17:14, Tim Blechmann wrote:
hi all ...
Also, what I would really prefer is to had support in Gem for LibMPEG2. Do you think it could be difficult to do ? Is it about creating a filmMPEG2.cpp and filmMPEG2.h files with the good function calls to the library and add the reference into the pix_filmNEW.cpp ?
correct. if you like to add libMPEG2-support you are welcome!
stupid question, but what about mplayer support instead of libMPEG2? mplayer is able to play back about every file format ...
just thinking loud ... tim
I know, it would be wonderfull...
But Mplayer is not a library. You can only use it as an application. Mplayer itself use LibMPEG2 to play MPEG2 stream and use other libraries for other formats and codecs (as FFMPEG, XVID, etc).
Unfortunately, I will not add LibMPEG2 to GEM. In fact I'll not use PD/GEM at all for the big project I'm working on. Maybe I'm crazy but the problem is that PD is not multithreaded and work with CPU time and not real time. So if you try in Gem to do something as simple as rotating a square on the screen, it will not rotate regularly. It will stall from time to time. And if you try to load a big texture (1024x1024) the rotation of the square will stall even more badly. And I don't think there's something I can do ? I tried to preload some big textures with pix_buffer but when I display the image it's sucking a lot of CPU. When I say a lot I mean a lot. The more your texture is big the more CPU it's suck. It's very strange. I don't understand why? Anyway, in the mid-term it's not an option for me to preload the images. So now I'm doing the project in Python with pyOpenGL. This way I can schedule redraw in real time, not cpu time, and open my textures in a thread. This way everything play smoothly. But I have a lot more to code ! I wish I could done it with PD/GEM but it's not possible.
One last note: for FFMEPG in Gem, I did try so many things but in the end it never worked. I always have the -2 error meaning that there's an I/O problem?
Anyway thanks for your good work to all the developers of PD and Gem !
Etienne