[olpc-software] XRes Improvements

[L. David Baron]

On Tuesday 2006-03-14 21:53 +0000, Daniel P. Berrange wrote:
> http://people.redhat.com/berrange/olpc/performance/

...in which you wrote:

# Running these tests revealed some interesting & unexpected results.
# The first test starting releasing pixmaps on the X server when total
# memory usage hit about 74 MB, with 12 pages loaded into history. The
# remaining tests *never* freed any pixmaps even after 50 pages / 220 MB
# of pixmaps are loaded. The stack traces associted with the XFreePixmap
# calls show some form of reference counting garbage collection is
# taking place to release pixmaps. The graphs would later tests suggest
# that this reference counting is broken when multiple tabs are open. On
# the plus side, the client side memory usage appears to be sane, with
# the only significant increase in usage being demonstrated when opening
# a new tab for every single web page loaded.

I tried some non-automated testing in trunk Firefox, and found (in gdb)
that XFreePixmap was being called when I expected it to be, even when
loading various images alternately between two tabs.  Loading new images
evicted old ones from the memory cache, calling XFreePixmap.  (I had to
weed out *tons* of other XFreePixmap calls related to temporary drawing
surfaces, and some related to Xft, though.)

I could try to see if I can replicate these results if I knew what
versions of both Firefox and Epiphany you were using.  Some versions are
nontrivial for me to build and install, especially since current
epiphany doesn't build on FC4 (it's too old!).

The reference counting shouldn't be too error-prone, although there are
actually multiple reference counts to care about, since the refcounted
nsImageGTK objects in Mozilla own a reference to refcounted GdkPixmap
objects which in turn own the pixmap.  I'd think Mozilla would be likely
to leak those nsImageGTK objects mainly in the case where it leaked a
substantial chunk of the data structures for the entire document, but I
could be wrong.

-David

-- 
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/olpc-software/attachments/20060314/7560fc4e/attachment.sig>