OpenOffice client freeze on print figured out (and other app freezes)

[Jim Kronebusch]

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.
 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.

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.