Thanks Mark, Chris and Guenter for the suggestion to check that GL was working. I looked at my X windows config file and it looks like GLcore wasn't enabled. I did enable it and Gem seems to be running better. I'll have a look at hdparm as well Chris,. One thing I would like to be able to do is fade out a running mpeg movie. I tried using pix_gain which works but slows down the mpeg movie. Can anyone suggest another way that is less processor intensive. Thanks for all the help. Jim
I second guenter's post about not having hardware GL working. did you get the nvidia drivers off the nvidia site? the ones that come with the linux distros are not the real drivers.
also, what size are these textures? and how many do you have? you could be running out of vram if you are trying to use a lot of large textures.
you are obviously using a laptop (geforce2go) so the hard drive could be slowing you down if it is full or you are trying to load massive amounts of data like 640x480 uncompressed movies or lots of files at once. also i find that sometimes dma transfers are off by default in linux. check man hdparm and http://linux.oreillynet.com/pub/a/linux/2000/06/29/hdparm.html for more info. this can make a big difference in disk transfer speed.
as far as the image distortion goes, this could be a case of resizing the texture to a power of two. i'm pretty sure that GEM supports non-power of two textures tho...
for resizing: mapping the movie onto a quad and resizing/scaling the quad should be the fastest method.
cgc
Hi,
I am having trouble scaling images using pix_draw. I thought I could scale an image using scale or scaleXYZ before pix_draw but it seems like these objects have no effect. I can scale an image by texture mapping onto a square and resizing it but I find it is slower than pix_draw in this case. When rendering movies I've found that texture mapping is faster but the image is more distorted. I'm using GEM 0.87 under Linux. Is this a problem with pix_draw or is it supposed to work this way? I have a fast processor ( 1 GHz) a good video card (Nvidia 2Go) and I find movies are playing quite slowly. I only have 128 MB ram. Just ordered another 256 MB hoping this will speed things up. Wondering what other people are using to get realtime playback with MPEGs in Linux? Thanks, Jim
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
--
For fading, use the OpenGL objects color and alpha. With color you can set the transparency by changing the the alpha channel, and the alpha object does nothing more than enabling alpha blending.
Other than pix_gain this uses OpenGL hardware and is therefore a lot faster.
Guenter
On Wed, 11 Sep 2002, Jim Ruxton wrote:
Thanks Mark, Chris and Guenter for the suggestion to check that GL was working. I looked at my X windows config file and it looks like GLcore wasn't enabled. I did enable it and Gem seems to be running better. I'll have a look at hdparm as well Chris,. One thing I would like to be able to do is fade out a running mpeg movie. I tried using pix_gain which works but slows down the mpeg movie. Can anyone suggest another way that is less processor intensive. Thanks for all the help. Jim
I second guenter's post about not having hardware GL working. did you get the nvidia drivers off the nvidia site? the ones that come with the linux distros are not the real drivers.
also, what size are these textures? and how many do you have? you could be running out of vram if you are trying to use a lot of large textures.
you are obviously using a laptop (geforce2go) so the hard drive could be slowing you down if it is full or you are trying to load massive amounts of data like 640x480 uncompressed movies or lots of files at once. also i find that sometimes dma transfers are off by default in linux. check man hdparm and http://linux.oreillynet.com/pub/a/linux/2000/06/29/hdparm.html for more info. this can make a big difference in disk transfer speed.
as far as the image distortion goes, this could be a case of resizing the texture to a power of two. i'm pretty sure that GEM supports non-power of two textures tho...
for resizing: mapping the movie onto a quad and resizing/scaling the quad should be the fastest method.
cgc
Hi,
I am having trouble scaling images using pix_draw. I thought I could scale an image using scale or scaleXYZ before pix_draw but it seems like these objects have no effect. I can scale an image by texture mapping onto a square and resizing it but I find it is slower than pix_draw in this case. When rendering movies I've found that texture mapping is faster but the image is more distorted. I'm using GEM 0.87 under Linux. Is this a problem with pix_draw or is it supposed to work this way? I have a fast processor ( 1 GHz) a good video card (Nvidia 2Go) and I find movies are playing quite slowly. I only have 128 MB ram. Just ordered another 256 MB hoping this will speed things up. Wondering what other people are using to get realtime playback with MPEGs in Linux? Thanks, Jim
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
--
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Thanks Guenter, This suggestion did exactly what I was looking for. I noticed when I use the " border 0" option with gemwin I can no longer bring other windows in front of the GEM window. Is there a way to still use "border 0" and have access to the windows beneath the GEM window. Also is it possible to open more than one GEM window? Thanks again. Jim
For fading, use the OpenGL objects color and alpha. With color you can set the transparency by changing the the alpha channel, and the alpha object does nothing more than enabling alpha blending.
Other than pix_gain this uses OpenGL hardware and is therefore a lot faster.
Guenter
On Wed, 11 Sep 2002, Jim Ruxton wrote:
Thanks Mark, Chris and Guenter for the suggestion to check that GL was working. I looked at my X windows config file and it looks like GLcore wasn't enabled. I did enable it and Gem seems to be running better. I'll have a look at hdparm as well Chris,. One thing I would like to be able to do is fade out a running mpeg movie. I tried using pix_gain which works but slows down the mpeg movie. Can anyone suggest another way that is less processor intensive. Thanks for all the help. Jim
I second guenter's post about not having hardware GL working. did you get the nvidia drivers off the nvidia site? the ones that come with the linux distros are not the real drivers.
also, what size are these textures? and how many do you have? you could be running out of vram if you are trying to use a lot of large textures.
you are obviously using a laptop (geforce2go) so the hard drive could be slowing you down if it is full or you are trying to load massive amounts of data like 640x480 uncompressed movies or lots of files at once. also i find that sometimes dma transfers are off by default in linux. check man hdparm and http://linux.oreillynet.com/pub/a/linux/2000/06/29/hdparm.html for more info. this can make a big difference in disk transfer speed.
as far as the image distortion goes, this could be a case of resizing the texture to a power of two. i'm pretty sure that GEM supports non-power of two textures tho...
for resizing: mapping the movie onto a quad and resizing/scaling the quad should be the fastest method.
cgc
Hi,
I am having trouble scaling images using pix_draw. I thought I could scale an image using scale or scaleXYZ before pix_draw but it seems like these objects have no effect. I can scale an image by texture mapping onto a square and resizing it but I find it is slower than pix_draw in this case. When rendering movies I've found that texture mapping is faster but the image is more distorted. I'm using GEM 0.87 under Linux. Is this a problem with pix_draw or is it supposed to work this way? I have a fast processor ( 1 GHz) a good video card (Nvidia 2Go) and I find movies are playing quite slowly. I only have 128 MB ram. Just ordered another 256 MB hoping this will speed things up. Wondering what other people are using to get realtime playback with MPEGs in Linux? Thanks, Jim
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
--
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
On Fri, 13 Sep 2002, Jim Ruxton wrote:
Thanks Guenter, This suggestion did exactly what I was looking for. I noticed when I use the " border 0" option with gemwin I can no longer bring other windows in front of the GEM window. Is there a way to still use "border 0" and have access to the windows beneath the GEM window. Also is it possible to open more than one GEM window? Thanks again.
GEM's "border 0" relies on X11's override_redirect feature, which bypasses the window manager (by just telling it to mind its own business). This has the side-effect of not putting any borders around, but also means you don't have any control anymore on that window, unless the window manager allows you to takeover a window that does not behave (i have not seen such a wm).
Another way to get a 0 border is with a window manager that lets you configure buttons and borders. WindowMaker allows this, on a per-program basis, and a per-window basis as well, and offers key combinations to manipulate the window without the need for dedicated surfaces like titlebar/buttons.
matju
On Fri, 13 Sep 2002, Jim Ruxton wrote:
Thanks Guenter, This suggestion did exactly what I was looking for. I noticed when I use the " border 0" option with gemwin I can no longer bring other windows in front of the GEM window. Is there a way to still use "border 0" and have access to the windows beneath the GEM window. Also is it possible
no, it's just as "windows" are handled by the window-manager real windows (with borders) are equal, but some (without borders) are more equal than others... btw, i do not see much sense in having this. using no borders is most likely for full-screen or similar (somehow "performance" mode). Maybe your patches should work by then without too much switching between windows ;-)
to open more than one GEM window? Thanks again.
no, not possible too. you can just create one single openGL-context (i hope i do not say something very stupid). Programs with multiple openGL-windows (like 3dmax) have 1 context that is devided into various subwindows -- the same happens with gem in stereo 1 mode. so you could emulate 2 subwindows with this stereo-mode (and with *very* queer eye-settings)
Jim
mfg.cds.dra IOhannes
Thanks Johannes and Mathieu for setting me straight on the operation of the GEM window. I found I can turn off the border with X windows and still have control over which window is on top. Jim
On Fri, 13 Sep 2002, Jim Ruxton wrote:
Thanks Guenter, This suggestion did exactly what I was looking for. I noticed when I use the " border 0" option with gemwin I can no longer bring other windows in front of the GEM window. Is there a way to still use "border 0" and have access to the windows beneath the GEM window. Also is it possible
no, it's just as "windows" are handled by the window-manager real windows (with borders) are equal, but some (without borders) are more equal than others... btw, i do not see much sense in having this. using no borders is most likely for full-screen or similar (somehow "performance" mode). Maybe your patches should work by then without too much switching between windows ;-)
to open more than one GEM window? Thanks again.
no, not possible too. you can just create one single openGL-context (i hope i do not say something very stupid). Programs with multiple openGL-windows (like 3dmax) have 1 context that is devided into various subwindows -- the same happens with gem in stereo 1 mode. so you could emulate 2 subwindows with this stereo-mode (and with *very* queer eye-settings)
Jim
mfg.cds.dra IOhannes
-
guenter geiger -
Jim Ruxton -
Johannes M Zmoelnig -
Mathieu Bouchard