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: 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) Chris
