OpenOffice client freeze on print figured out (and other app freezes)
jim at winonacotter.org
Tue Sep 18 13:38:40 UTC 2007
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
make it look like the options to disable pixmaps are not related to only the ATI driver.
Scott, you stated that this only affects ATI drivers, but I can't find that stated in
xorg man pages. Where did you find that? 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.
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:
Disables accelerated draws into pixmaps stored in offscreen
Disables caching of patterns in offscreen video memory.
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" "On"
Option "Accel" "false"
Option "Accel" "no"
Cotter Tech Department
This message has been scanned for viruses and
dangerous content by the Cotter Technology
Department, and is believed to be clean.
More information about the edubuntu-devel