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