Well it appears the problem does go back to the same pixmap cache crap that is happening with Firefox. OpenOffice does not cache the graphics to X until you go to print. Then it appears it sends as much as possible to the printer, when the printer RAM is full then the remainder is cached to X. So when I print the test document to my low memory printer (HP 4000N connected via jetdirect and 4MB RAM) xrestop shows pixmap cache climbing to 91MB before taming back down (hence my freeze on the client). But when I print the same document from the same client, xrestop shows the pixmap cache only hitting 25MB before finishing the print job. During this time is when mouse movement gets choppy. I was able to test this by putting a hard drive in my client and loading a full OS, which allowed for fast enough swap that it didn't crash and I was finally able to see accurate results from xrestop.
So now I assume I understand the Impress problems as well. OpenOffice does not cache pixmaps in Impress...until you run the slideshow. Then the image pixmaps are cached to X and the client freezes. I am sure with a bunch of other testing we'd find similar problems with Totem and Tuxpaint or Gcompris and other graphically intense programs. So now I feel the focus shouldn't be on patching Firefox (although that wouldn't hurt) but on figuring out how to tell xorg not to cache pixmaps for any application, or to give pixmap caching a limit of say 25MB or at least have an option in lts.conf to set PIXMAP_CACHE_SIZE=25MB or something. So now I have been reading the man pages on xorg. These are some snips I pulled from this webpage http://bardolph.ling.ohio-state.edu/cgi-bin/dwww?type=runman&location=xorg.conf/5 which make it look like the options to disable pixmaps are not related to only the ATI driver. However in my testing last night on a Intel 810 I could not disable pixmap caching to save my life. I think I will join an xorg mailing list and see if I can find more answers. But I still feel a little better that I feel I know what the problem is now (with all application freezes) and feel a little better equipped to get this figured out. As far as the next UDS, I may be overstepping my bounds here, but I think this would be an excellent high priority topic for the developers to focus on as pixmap caching seems to be the main thing causing instability in many apps on the thin clients. If this was figured out I think any concerns on client stability would almost cease. Jim SCREEN SECTION The config file may have multiple Screen sections. There must be at least one, for the "screen" being used. A "screen" represents the binding of a graphics device (Device section) and a monitor (Monitor section). A Screen section is considered "active" if it is referenced by an active ServerLayout section or by the -screen command line option. If neither of those is present, the first Screen section found in the config file is considered the active one. Screen sections have the following format: Section "Screen" Identifier "name" Device "devid" Monitor "monid" entries ... SubSection "Display" entries ... EndSubSection ... EndSection Option "XaaNoOffscreenPixmaps" Disables accelerated draws into pixmaps stored in offscreen video memory. Option "XaaNoPixmapCache" Disables caching of patterns in offscreen video memory. Option "Accel" Enables XAA (X Acceleration Architecture), a mechanism that makes video cards' 2D hardware acceleration available to the __xservername__ server. This option is on by default, but it may be necessary to turn it off if there are bugs in the driver. There are many options to disable specific accelerated opera- tions, listed below. Note that disabling an operation will have no effect if the operation is not accelerated (whether due to lack of support in the hardware or in the driver). Example: the following option entries are equivalent: Option "Accel" "Off" Option "NoAccel" Option "NoAccel" "On" Option "Accel" "false" Option "Accel" "no" Jim Kronebusch Cotter Tech Department 453-5188 -- This message has been scanned for viruses and dangerous content by the Cotter Technology Department, and is believed to be clean. -- edubuntu-users mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-users
