[Spice-devel] Render measurements

[Søren Sandmann]

This branch here:

    http://cgit.freedesktop.org/~sandmann/xf86-video-qxl/log/?h=trackimages

will produce various types of information in the X log file when the
option "EnableImageStats" is given in xorg.conf. Specifically, it will
track whenever an operation triggers a fallback and record the number
of (uncompressed) bytes in the resulting image upload along with a
reason that the fallback happened.

This repository:

     http://cgit.freedesktop.org/~sandmann/imganalysis/tree/

contains a Python script that will read the resulting X log files and
do some rudimentary analysis on it. There is also a set of log files
generated as follows:

cnn.log:
        - Log in
        - Open Firefox
        - Go to www.cnn.com

pinterest.log:
        - Log in 
        - Open Firefox
        - Go to pinterest.com
        - Scroll down for a good while (the site has inifinte scrolling)

oofice.log:
        - Log in
        - Open OpenOffice writer
        - Open this document:  
               http://www.freedesktop.org/~sandmann/tutorialOOoBase.odt
               - Scroll to the end

Each type of log file exists with image caching turned on and
off. Caching of *fallback* images was turned on in all cases.

The results are available in the attached Gnumeric spreadsheet. The
main interesting number is 'Estimated saving from Render excluding
nomask', which is 73% with image caching on and 74% with image caching
off. This number corresponds to uncompressed image bytes in Render
requests that cannot be implemented with existing SPICE protocol
commands.

The "including nomask" number includes requests that could potentially
be implemented with the existing AlphaBlend command.

The conclusion is that adding Render acceleration will save around 88%
bandwidth, but that around 17% of those could *possibly* be saved
without changing the protocol.

Some caveats:

- With Render acceleration, some bandwidth will still be used for the
  commands themselves. I don't know how much this will be precisely.

- The numbers are before compression. It's conceivably that the types of
  images generated by Render requests are more or less compressable than
  those of other types of requests


Soren


-------------- next part --------------
A non-text attachment was scrubbed...
Name: analysis.gnumeric
Type: application/x-gnumeric
Size: 3724 bytes
Desc: Data
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20120507/0619ff23/attachment.gnumeric>