Created attachment 562094 [details] [diff] [review] patch I'm assuming maemo is the only distro we know of with this broken x server
Comment on attachment 562094 [details] [diff] [review] patch There are two reasons this was added (1) Maemo doesn't have very good X drivers (don't use the GPU). So X ends up falling back on pixman for compositing. That's bad because the pixman used by X is always going to be older than the version shipped with Firefox. That means we're missing out on optmizations added to newer pixman, which in practice means new NEON fast paths. This problem isn't specific to mobile (true for any desktop with bad drivers), but it's worse because of the rate of NEON optimizations added. (2) In a multiprocess world where X has bad drivers, it's stupid for us to have X draw both the UI and content. X is single threaded which means requests are serialized across chrome/content and run on the CPU. So we throw a lot of the gain we'd get from multiprocess out the window, since content drawing itself could *still* block the UI, by overloading the X server, and we don't control the priority of requests within the X server. This problem isn't specific to maemo or mobile at all, but it's worse there since responsiveness is more important. (When X uses the GPU, things become more complicated. We don't have a good solution for that yet.) Ideally we would use some kind of dynamic feature detection / autotuning step like I mentioned in another bug to figure out when we should use client-side rendering. There are lots of desktop/notebook machines where this makes sense (and it will make more sense when we have multi-process there), and indeed a community member found some sites that ran like shit in FF, much better in Chrome, that were improved greatly by enabling client-side rendering. But until we have that, I'm fine with limiting this to maemo. It'd be great if you could update the comment per above.
pushed to inbound with an updated comment https://hg.mozilla.org/integration/mozilla-inbound/rev/7a98f72a4979