On 12/07/14 3:46 PM, Chris Cappuccio wrote:
Kevin Chadwick [[email protected]] wrote:
I'm guessing this is due to the new KMS 3d support not being as fast
right now but much better than you had before.
It also affects Thunderbird. Here's my synopsis of Mark Kettenis's
analysis:
The quoted text from Kevin is out of context. He was replying to
the paragraph regarding video playback performance, but KMS isn't
the issue there.
Firefox uses an old version of cairo. This cairo library uses XGetImage
to get the image copied back to a ZPixmap in user space. It copies with
a 4k buffer size (the default). So your extremely large, uncompressed image
gets copied in 4k chunks with constant context switches.
Not only do the subsystems thrash themselves, but the server sends the
image in non-blocking mode, and the socket buffer is full, it fails with
EAGAIN and discards the data already sent by copying the remaining data to
the start of the buffer, waits for the socket to drain and tries again when
the socket is ready.
You can find Mark's buffer size improvement here:
http://comments.gmane.org/gmane.os.openbsd.cvs/128950
http://lists.x.org/archives/xorg-devel/2014-March/041543.html
This makes the problem less apparent.
Some in the ports tree tried using a newer cairo and found a whole new
set of problems (apparently firefox depends on old cairo and/or local
modifications to it)
Why Firefox needs a ZPixmap of the image displayed, that is, the entire
fully uncompressed image copied back to userland in 4k (or 64k) chunks,
that's totally beyond me, by itself. Why the X server does it in such
a poor way, beyond me. It's crazyland!!!
Playing video in browsers and even displaying pictures is a
surprisingly resource hungry task with umpteen potential rules working
out what shape and where everything should be and unfortunately more
effort has been spent on javascript performance than rendering.
These issues are not directly related (and largely solved when the X
clients use the right techniques, which sometimes vary between platforms
and display drivers)
The video playback issues are more to do with the relatively poor MP /
pthreads performance on OpenBSD.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
