From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010712 Description of problem: None of GL-xscreensavers are accelerated. I'm using partial rawhide here. I'm still relactant to try XFree86-4.1.0, maybe, this is the reason. In that case xscreensaver should have required that version. I checked that direct rendering is enabled and gears spin like crazy. How reproducible: Always Steps to Reproduce: 1. TRy 2. 3. Additional info:
I'm not sure what you're saying - they're accelerated when run in a window but not when run as a screen saver?
I mean that gears from Mesa-demo are smooth fast while gears and Co from xscreensaver are slooooow and jumpy.
*boggle* I don't see how this could happen. Did you build the Mesa-demo stuff from source, or is it from the RPM? Do you have any non-standard libGLs installed?
I have XFree86-4.0.3-22 with Mesa-3.4.2-1 from 2-week old rawhide. xscreensaver- 3.32-2 works well with it. The new release (3.33-2) does not have acceleration. I mean the frame rate is 10 times lower than one would expect using DRI. I was surprised by that and checked if my DRI stayed enaled. It did and gears from an older Mesa-demo-3.4.2-1 worked fast. What I mean is that it's not a problem in my set-up, but rather xscreensaver-3.33-2's problem. I couldn't be more clear. You probably compiled this new release using XFree-4.1.0-something libraries. The new XFree86 or Mesa probably have something incompatibly changed. I don't know. The bottom line - xscreensaver lost 3d acceleration on an older system. Maybe, it was supposed to happen. I don't know.
I understand what you're saying. I'm just saying that by everything that I know, this *shouldn't* happen (i.e., it shouldn't matter which libGL it links against.) Just to confirm, if you rebuild 3.33-2 on your system, does it work fine?
In the config file .xscreensaver of your home directory change Memory Limit from 50M to 100M. That it's enough to make it works. I don't know if its two much or not.
Reporter: does that work for you?
(if so, we'll bump the default to something reasonable, but higher.)
Confirmed here; setting the memory limit higher should fix the problem.
Setting memory higher doesn't change anyuthing for me. However, I found out that the problem exists only when using "Demo" in xscreensaver-demo. Starting them from command line or by the daemon works fine, with acceleration. Strange, huh? In addition, default frame delay values are too high in my opinion given the fact that dealy is simply added to the elapsed time in rendering. :( It should be that delay exists only if the rendering took less time than the value specifies.
Yeah... Maybe, the rendering is accelerated, but delay values while starting through "demo" are set too high?
I does appear that DRI works only by firing up the modules from command line. daemon and xscreensaver-demo do not start the modules correctly.
Setting memory to 250M doesn't help. From daemon glpnanet consumes 0.1% with X eating away 99.5%. From command line 75% for glplanet with almost nothing for X. Please check how the daemon (and xscreensaver-demo) controls the modules. I'm downgrading to 3.32-3 for now this is my last report here.
This was fixed in the build in 7.2.