The problem you see has to do with DirectShow using a different set of coordinates for drawing. An AVI clip opened with pix_film that also uses DirectShow should not have this problem. An updated version of GEM that does this can be found at
<a href="http://gem.iem.at/download/SNAPSHOTS/gem-CVS20060914-w32-i686-bin-doc.zip">http://gem.iem.at/download/SNAPSHOTS/gem-CVS20060914-w32-i686-bin-doc.zip</a><br><br>pix_draw is not the fastest way to get images drawn. Try pix_texture and the rectangle object. A 640x480 or 1024x768 window is filled with [rectangle
5.33 4].<br><br><div><span class="gmail_quote">On 12/8/06, <b class="gmail_sendername"><a href="mailto:cdriko@free.fr">cdriko@free.fr</a></b> <<a href="mailto:cdriko@free.fr">cdriko@free.fr</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br>thanks for your help<br><br>About compositing 3D<br>I can't use pix_snap because my GLoutput is in 1024 768<br>and I think that the computer will cry to pix_snap and pix_resize<br>continuously<br><br><br>About the problem with the pix_mix object
<br>at the begining, I put a pix_flip object before the right inlet<br>with a result strange : picture is alternativelly flipped up and down<br><br>the solution that I found is by the pix_film source object :<br>before, I used a metro to changing number of image
<br>(to get the possibility to change the rate)<br><br>in fact, if I replace this metro by a derivating bang from the gemhead of the<br>pix_film, the path pix_flip>pix_mix is working well<br><br>You can see the exemple patch next
<br><br>the last problem is that, if I put a rate < 1 (in the |pd lecteur_video_boucle|)<br>the hysteric flip is recoming<br><br>but it's now very better!!!!<br><br></blockquote></div><br>