hello
I would like to use GEM for programming experimental user interfaces. The problem I have is that sometimes GEM works very well, whereas sometimes it's very slow.
For example, when I draw only 4 white mouse-movable squares over a black background, in a 300x300 window, the performances are good (in full screen too). But if I replace the background by a small PNG image (about 12 ko), GEM slows the program a lot (there are cuts in the audio stream). This happens under Windows XP with a recent computer and a usual graphic card. Is it normal ?
In which cases does GEM become slow like this ? Should I rather use GEM under Linux ? Or, maybe GEM is rather adapted to Open GL than image or video matrix processing ?
Thanks for your help
On Feb 18, 2004, at 7:43 PM, julien.breval@tremplin-utc.net wrote:
For example, when I draw only 4 white mouse-movable squares over a black background, in a 300x300 window, the performances are good (in full screen too). But if I replace the background by a small PNG image (about 12 ko), GEM slows the program a lot (there are cuts in the audio stream). This happens under Windows XP with a recent computer and a usual graphic card. Is it normal ?
One problem is that GEM on windows only handles power-of-two textures
(64, 256, 512, etc). So if you have a 300x300 image that becomes
512x512 in OpenGL on windows. With small static images you should not
have any sort of performance issue even on very old hardware. What
type of hardware are you using? And what does your patch look like?
pix_image with pix_texture will only texture the images once after they
are loaded so there would not be any constant performance drain. Also,
dropouts in the audio are pretty much a part of pd right now and it
might not even be the GL stuff causing you problems. Some relatively
minor looking pd GUI elements can take a surprising amount of CPU.
In which cases does GEM become slow like this ? Should I rather use GEM under Linux ? Or, maybe GEM is rather adapted to Open GL than image or video matrix processing ?
If you are only doing four squares with small images on them and your hardware is fairly recent then there is something else wrong that moving to another OS would only fix by accident. I can only throw out guesses without knowing more.
cgc
Thanks for your help
--
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
One problem is that GEM on windows only handles power-of-two textures (64, 256, 512, etc). So if you have a 300x300 image that becomes 512x512 in OpenGL on windows. With small static images you should not have any sort of performance issue even on very old hardware. What type of hardware are you using?
Intel 82845G Graphics Controller (internal video device), with a recent PC (Pentium 4 2.4 GHz, RAM = 512 Mo)
And what does your patch look like?
There is a constant picture as a background ; above this picture there are 4 small GL squares that repreasent four (x,y) positions ; you can move these squares with the mouse
I'm sorry I didn't know that pictures sould have a size of a power-of-2 ; in this case, I would like to use 512 x 512 pictures
Also, dropouts in the audio are pretty much a part of pd right now and it might not even be the GL stuff causing you problems.
not in that precise case, because without the new GEM "user interface" there is no problem ; moreover, when I replace the image by a constant background colour, it works very well
Maybe I should try with power-of-2 images or smaller images
Some relatively minor looking pd GUI elements can take a surprising amount of CPU.
If you are talking about the graphic [bang]or other Tcl/Tk graphics (Array, etc), I agree, but there is no stuff like this either in my patch (at least as few as possible, and hidden in subpatches)
There is a HUGE speed difference depending if you use [pix_texture] or [pix_draw]
that was the problem, sorry for this
by the way, thanks to the [pix_texture2] object, you can use any image size
One problem is that GEM on windows only handles power-of-two textures (64, 256, 512, etc). So if you have a 300x300 image that becomes 512x512 in OpenGL on windows. With small static images you should not have any sort of performance issue even on very old hardware. What type of hardware are you using?
Intel 82845G Graphics Controller (internal video device), with a recent PC (Pentium 4 2.4 GHz, RAM = 512 Mo)
And what does your patch look like?
There is a constant picture as a background ; above this picture there are 4
small GL squares that repreasent four (x,y) positions ; you can move these squares with the mouse
I'm sorry I didn't know that pictures sould have a size of a power-of-2 ; in
this case, I would like to use 512 x 512 pictures
Also, dropouts in the audio are pretty much a part of pd right now and it might not even be the GL stuff causing you problems.
not in that precise case, because without the new GEM "user interface" there is no problem ; moreover, when I replace the image by a constant background colour, it works very well
Maybe I should try with power-of-2 images or smaller images
Some relatively minor looking pd GUI elements can take a surprising amount of CPU.
If you are talking about the graphic [bang]or other Tcl/Tk graphics (Array,
etc), I agree, but there is no stuff like this either in my patch (at least as few as possible, and hidden in subpatches)
Quoting julien.breval@tremplin-utc.net:
There is a HUGE speed difference depending if you use [pix_texture] or
[pix_draw]
that was the problem, sorry for this
by the way, thanks to the [pix_texture2] object, you can use any image size
Well, you still need an actual video card rather than that Intel chip to do much of anything useful in GEM. pix_texture2 is actually gone from GEM now, and in any case it doesn't really do arbitrary image sizes on Windows it just uses black pixels to fill in the rest of the power of two texture. It's very inefficient.
cgc
Quoting julien.breval@tremplin-utc.net:
One problem is that GEM on windows only handles power-of-two textures
(64, 256, 512, etc). So if you have a 300x300 image that becomes 512x512 in OpenGL on windows. With small static images you should not
have any sort of performance issue even on very old hardware. What type of hardware are you using?
Intel 82845G Graphics Controller (internal video device), with a recent PC (Pentium 4 2.4 GHz, RAM = 512 Mo)
Oh say no more, this is a huge part of your performance problem. The only thing Extreme about Intel's graphics chips is how bad they perform. Just about any AGP card will give you a huge boost in speed and offload all of the textures from main memory to the video card.
cgc
-
cgc -
cgc＠humboldtblvd.com
-
julien.breval＠tremplin-utc.net