- I am using a Pentium III 866 machine, so if our problems are related, I
don't think the cause is the processor.
- While there is a netreceive object in my patch, I have not had a socket
connection open for most of my testing.
- In addition to my previously mentioned problem of rendering large font
sizes using nearly 100% CPU, using the pix_draw object also consumes nearly 100% CPU. Again, this CPU usage is from XF86 4.0 and not from pd.
- To circumvent my current problem, I've redone all the text in my patch as
images and texture mapped them to squares. While this consumes very little processor time, it is rather memory hungry (both from pd and from X). But it seems to work for now.
- One more problem of note: With the nVidia drivers only (not with MesaGL),
my Xserver crashes whenever I switch workspaces and a GEM window is open with rendering turned on. If I turn rendering off, then I can switch workspaces with no problems.
Any suggestions about any of the problems, or the previously mentioned problem of the text3d object causing pd/GEM to crash, would be greatly appreciated.
Thanks! --Jason
on 6/19/00 4:04 AM, forum::für::umläute wrote:
leberre@convergence.de wrote:
- Jason Freeman (jason_freeman34@hotmail.com) [000616 21:52]:
Hi all -- I'm having some problems with truetype font rendering in pd/GEM, and was wondering if anyone else has had similar problems or has any suggestions. I am using a Dell 866 Pentium machine with Red Hat 6.2, a TNT2 chipset graphics card, and the nVIDIA OpenGL drivers and XFree86 4.0 and freetype 1.3.1.
- The "text3d" object does not work at all. When trying to use the example
patch included with gem 0.83, for instance, pd/GEM crashes as soon as I turn on rendering. I previously had this same problem on a similar linux machine that was just using the standard Mesa3d drivers. There are no error messages prior to crashing.
- The "text2d" object is incredibly power hungry with large font sizes.
Pd's CPU usage stays very low, but as I increase the font size of a "text2d" object, even if it only contains a single character, the X server CPU usage quickly jumps to almost 100%. This did not happen on other machines that were using Mesa3d drivers instead of the nVidia GL drivers.
Any ideas would be appreciated -- or even clues as to whether the problem lies in GEM, the nvidia drivers, or the freetype libraries.
I experienced the same thing using GEM on a new powerbook g3 running linuxppc.
In fact, for me, when I try to run an example using text, (gemChangeText.pd for example) the program look for the "arial.ttf", and it didn't find it because it is named "Arial.ttf". I rename the "Arial" into "arial" without more success.
on mesaGL machines:: I really did solve this problem by renaming "Arial.ttf" to "arial.ttf"; the wrong uppercase seems to derived from using MS's Win32 platforms and porting filesystems to Linux... then i am using freetype-1.3.1 too, so i do not think that this is the problem
on machines with nVidiaGL drivers:: i needed to do graphics with a number of various objects (very basic ones, cubes, spheres, cylinders, teapots, ...) being texturized and moved; mesaGL is definitely too slow (just look at the gem2.moveImages.pd -demopatch for textures (uähh)) so i tried hardware-acceleration I experienced several unstabilities when using a an ErazorX2 (with the Geforce256 chipset) on an Athlon K7-650MHz System, running Debian with kernel-2.2.15 (kernel-2.4 (featuring SlotA-mainboards) was REALLY unstable...), freetype-1.3.1 XFree4.0 and nVidia's native drivers 0.9-2. I had a very hard time getting the XFree4.0 to run (there is no Debian support yet !) and needed another week or so to kill all hints of mesaGL; using the hardware-acceleration of the card was really cool by then (and very fast: CPU load of 5%-10% total), but still i have a problem concerning screen-freezes; there are two kinds or these crashes ::
- Screen freezes and X needs 98.0 to 99.5 percent of the CPU; this is
the good case since the computer is still controlable; (i think) pd still reacts to netcommands it seems to me, as if Jason experienced a very similar scenario : since i am not using any "font" objects at all, it is quite unlikely to search for the bug in the freetype-libs. 2. Screen freezes and computer locks completely (can't "ping" it anymore !); the only way to get out of this is to kick the reset-button. (or do another power-failure); this is obviously the bad case
I thought the problem was :: a) on the AMD-system (very likely; i will have some tries this week on a very similar system-configuration but with a PIII-733 processor and an ASUS-v6600 card (same chip)) which processor do you use, Jason ? b) hidden in the XFree4.0, since it seems as if this was still quite unstable (therefore it is not yet released with Debian) c) on the netsend/netreceive-objects in pd; we are using three PC's that are connected via ethernet; since the TCP/IP connection was very crashy (even when all the PC's where running, not to mention the problems, when one of them crashed/was rebooting or something similar.), we decided to use UDP; not using the netconnection a test-patch did quite well (for about 12 hours, then i stopped testing since i had work to do); using the netreceive (the graphical-interface is slave) led to the mentioned crashes, but i'm not very sure if this is really the problem
on the other hand, i think, Jason's text - problem might not be connected to the net, at least, I do believe that your core-testpatch doesn't have netconnection, does it ?
mfg.fasd.t iohannes