2020-11-19
Firefox on Linux has not worked well with WebRender for me so far
A while back I wrote about my confusion over Firefox's hardware accelerated video on Linux; as part of that confusion, I attempted to turn on all of the preferences and options necessary to make hardware accelerated video work. Part of the requirements is (or was) forcing on WebRender (also), which is in large part about having the GPU do a lot more web page rendering than it does in Firefox today. Even after I seemed to not get hardware accelerated video, I left WebRender turned on in the Firefox instance I was using for this. Well, at least for a while. After a while I noticed that that Firefox instance seemed more prone to jank than it had been before when I did things like flip back to a Firefox window I hadn't been using for a while. Reverting WebRender back to the default setting of being off fixed the problem.
(I probably turned this off around the time of Firefox 81.)
Very recently, my personal build of Firefox Nightly started
experiencing weird jank. Most of
my Firefox windows are on my first (primary) fvwm
virtual page and performed normally, but the moment I flipped to
another virtual page (often to substitute for not having dual
monitors right now) the
Firefox window (or windows) that was on that new page would get
extremely slow to respond. Today I determined that this was due to
WebRender recently getting turned on by default in my Nightly
environment; forcing WebRender off via gfx.webrender.force-disabled
eliminated the problem. I cross-checked about:support output
between my old normal Nightly build and the new Nightly build while
it had the jank problem and verified that the only difference was
WebRender (and hardware rendering) being turned on.
(This change is so recent it's not on the WebRender status page, which still says that WebRender is not enabled on large screens like mine on Intel GPUs. The change is bugzilla #1675768.)
Unfortunately this is not a simple problem. It's not an issue of excessive CPU or GPU usage, as far as I can tell, and it's not caused simply by having a Firefox window in an additional fvwm virtual page, because it doesn't happen in a test Firefox profile that's running the same binary. That it happens only if I move virtual pages makes it rather odd, because fvwm actually implements changing between virtual pages by moving all of the windows that aren't supposed to be there to off screen (and moving all of the other ones back on). So a Firefox window on the screen sees no difference in X11 protocol level window coordinates regardless of what virtual page fvwm is displaying (although offscreen Firefox windows will have different coordinates).
(I've also tried running Firefox with the environment variable 'INTEL_DEBUG=perf', from here, and there's no smoking gun. However, the change's bug mentions 'vsync' every so often and as far as I can see there's no way I can check for excessive waits for vsync, which could be one source of stalls.)
PS: Because I use fvwm, bug #1479135 - Black border around popups with non-compositing window manager usually makes it pretty obvious if WebRender is on in one of my Firefox instances (I use uBlock Origin's on the fly element picker a lot, which requires calling up its addon menu, which shows these black borders).
Apple Silicon Macs versus ARM PCs
In a comment on my entry on how I don't expect to have an ARM-based PC any time soon, Jonathan said:
My big takeaway from the latest release of Apple laptops is that these new laptops aren't necessarily ARM laptops. [...]
When a person gets an Apple Silicon Mac, they are not getting an ARM computer. They are getting an Apple computer.
As it happens, I mostly agree with this view of the new Apple
machines (and it got some good responses on tildes.net).
These Apple Silicon Macs are ARM PCs in that they are general purpose
computers (as much as any other OS X macOS machine)
and that they use the ARM instruction set. But they are not 'ARM
PCs' in two other ways. First, they're not machines that will run
any OS you want or even very many OSes. The odds are pretty good
that they're not going to be running anything other than OS
X macOS any time soon (see Matthew Garrett).
Part of that is because these machines use a custom set of hardware around their ARM CPU and Apple has no particular reason to document that hardware so that anyone else can talk to it. In the x86 PC world, hardware and BIOS documentation exists (to the extent that it does) and standards exist (to the extent that they do) because there are a bunch of independent parties all involved in putting machines together, so they need to talk to each other and work with each other. There is nothing like that in Apple Silicon Macs; Apple is fully integrated from close to the ground up. The only reason Apple has for using standards is if they make Apple's life easier.
(Thus, I suspect that there is PCIe somewhere in those Macs.)
Second, they don't use standard hardware components and interfaces. This isn't just an issue of being able to change pieces out when they break or when they don't fit your needs (or when you want to improve the machine without replacing it entirely). It also means that work to support Apple Silicon Macs doesn't help any other hypothetical ARM PC, and vice versa. To really have 'ARM PCs' in the way that there are 'x86 PCs', you need standards, and to get those standards you probably need component based systems. If everyone is making bespoke SoC machines, you have to pray that they find higher level standards compelling, and those standards are useful enough.
(Even laptop x86 PCs are strongly component based, although often those components are soldered in place. This is one reason why Linux and other free OSes often mostly or entirely just works on new laptop models.)
PS: My feeling is that there is no single 'desktop market' where we can say that it does or doesn't want machines with components that it can swap or mix and match. There is certainly a market segment that demands that, and a larger one that wants at least the lesser version of adding RAM, replacing the GPU, and swapping and adding disks. But there is also a corporate desktop market where they buy little boxes in a specific configuration and never open them, and I suspect it has a bigger dollar volume.