nVIDIA woes (Was: Freetype woes)

[umläute]

leberre at convergence.de wrote:
> 
> * Jason Freeman (jason_freeman34 at 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.
> >
> > 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.
> >
> > 2) 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 ::
1. 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