Hi,
Sounds great, the results look promising.
Did you check if there are other operations, besides the "nomask" ones,
that can be translated to the current QXL_DRAW commands, mainly the
QXL_DRAW_ROP3 one?
* The number of cached bytes displayed in the spreadsheet is larger when
caching is off. Mistake on the spreadsheet? Or just difference in the
websites content?
Cheers,
Yonit.
On 05/07/2012 07:45 PM, Søren Sandmann wrote:
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
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel