Try changing the GL_RGB to GL_RGBA in the snapMess() function in pix_snap2tex.cpp and see what happens. <br><br>cgc<br><br><div><span class="gmail_quote">On 8/19/06, <b class="gmail_sendername">Frank Barknecht</b> <<a href="mailto:fbar@footils.org">
fbar@footils.org</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;">Hallo,<br>chris clepper hat gesagt: // chris clepper wrote:
<br><br>> On 8/19/06, Frank Barknecht <<a href="mailto:fbar@footils.org">fbar@footils.org</a>> wrote:<br>> ><br>> >Thanks for your help. I tried with the Cube now, so far only on my<br>> >Matrox, where I get the same results: CPU usage goes up to 99-100
<br>> >percent immediatly. The patch seems to run fine otherwise...<br>><br>><br>> Sounds like a Matrox problem. On my nearly obsolete Powerbook the patch<br>> takes under 3% CPU with the cube. Your system might be downloading the
<br>> textures to the CPU for manipulation and then uploading them again. This is<br>> the same as using pix_snap followed by pix_texture.<br><br>This sounds quite sensible. I now also tested the cube-version on my
<br>Intel-laptop. I also get very high load, though only about 80 percent)<br>and crappy performance. Disabling the gemhead of the snap2tex lets CPU<br>usage drop to about zero immediatly.<br><br>Maybe it's a problem with the OpenGL libraries or with AGP on my
<br>systems. One is a Debian, the other an Ubuntu box, and I didn't do any<br>special configuration.<br><br>Maybe some other Debian/Linux users can give some hints here?<br>IOhannes, you are running Debian as well, btu I guess with NVidia...
<br><br>Ciao<br>--<br> Frank Barknecht _ ______footils.org_ __goto10.org__<br><br>_______________________________________________<br>GEM-dev mailing list<br><a href="mailto:GEM-dev@iem.at">GEM-dev@iem.at</a>
<br><a href="http://lists.puredata.info/listinfo/gem-dev">http://lists.puredata.info/listinfo/gem-dev</a><br></blockquote></div><br>