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

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


-- 
edubuntu-devel mailing list
edubuntu-devellists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-devel