Every single time I decide that I'm moving to Linux, I give up after living with the browsers for a day or two. Rendering and fonts are just inferior to other systems in my experience.
Well, Chrome OS runs the same stuff as your average Linux distro, however maybe most distros don't turn on subpixel antialiasing in their FontConfig out of the box. (I don't know because I've been sharing configs between machines of the same distro for about five years).
https://www.chromium.org/blink/slimming-paint
https://www.chromium.org/developers/design-documents/gpu-acc...
Skia can only use what the underlying graphics drivers offer.
With HiDPI, that doesn't matter anyway.
Another issue are fonts themselves. If you have a document that uses Arial or Cambria or another proprietary font, and you don't have it installed, you are going to get something substituted, which may or may be not metrics-compatible. Do not expect pixel-identical results then.
If I'm not mistaken, those patents are dead now. Even Fedora has the freeworld stuff now.
> Another issue are fonts themselves. If you have a document that uses Arial or Cambria or another proprietary font, and you don't have it installed, you are going to get something substituted, which may or may be not metrics-compatible. Do not expect pixel-identical results then.
Yeah, though the Chrome OS core fonts are good metric-compatible substitutes for Arial and friends (though lacking the stylistic variety of the core Windows fonts).
Not the subpixel rendering ones ("cleartype"). In Fedora, FT_CONFIG_OPTION_SUBPIXEL_RENDERING is still disabled.
Google also released metric compatible substitutes for Cambria (Caladea) and Calibri (Carlito), but Linux distributions do not install them by default.
Edit: I'm wrong. In F27, the subpixel rendering is enabled.
Not everyone wants to replicate a PDP-11.
I for one do not feel windows has a good story if you're developping anything you don't use VS for.
A world where GNOME and KDE developers get bashed upon, when trying to bring UI/UX into a modern world.
What GPU is this?
> only beaten by macOS
Well, you said you wanted "proper GPU acceleration", macOS GPU drivers are terrible. They're unstable, they have limp shader compilers, they are CPU-intensive, and in the case of OpenGL, they are behind by nearly six years in terms of features. Today, your sleek MacBook Pro supports considerably fewer modern GPU features than your average entry-level smartphone. You're missing stuff like multi draw indirect, texture clears, 8-bit stencils, image copying, explicit uniform location...
> hibernation that actually works
Well, I have that set up (and in my case it really has to be optional, since I have a really disk-scarce device right now). It worked correctly. I believe systemd will even monitor my battery and hibernate before it gets too low, like you'd expect (though maybe it could be brought out of hibernation enough times in a row to eventually run out of power before systemd gets to it). Maybe there should be a smoother transition between suspend and suspend-to-disk like macs with macOS have, but that isn't strictly necessary.
Any capable of DirectX 12, but only gets OpenGL 4.3 drivers or similar on GNU/Linux.
Or my AMD Brazos one on a Linux netbook, DirectX 11 class, which only gets OpenGL 3.3 drivers.
Regarding OpenGL on macOS, I don't care, that is what rendering engines are for, and all relevant ones already support Metal 2.
What GPU is this? I don't know of a DX12 device which lacks OpenGL 4.5 support in a stable release of Mesa (or the blob, in the case of NVIDIA, since they are uncooperative with regard to firmware).
> Regarding OpenGL on macOS, I don't care, that is what rendering engines are for, and all relevant ones already support Metal 2.
Sure, if you're running only games, and those that were made before 2012, and after 2017, then that works fine. For an example of something that does not currently use Metal (2 or no 2): any web browser (to my knowledge, including Apple's own, except as a backend for the WebGPU prototype), professional graphics application, or visualization utility. The shader compiler is still subpar, even in Metal.
> Or my AMD Brazos one on a Linux netbook, DirectX 11 class, which only gets OpenGL 3.3 drivers.
IIRC Brazos in that range would be... Radeon HD 6330M, and you're right, that should support GL 4.4. If you're running Mesa from 2016 or later, it should have 4.1 (and most extensions, except compute shaders, up to 4.4), if you run AMD's blob you can probably get 4.4 on it today. Work on drivers for pre-southern-islands devices is slow these days, but anything after SI has full certified OpenGL 4.5 on Mesa along with every extension in in 4.6 except for SPIR-V loading (coming soon), and the performance is better in basically all cases than it is on Windows, or with the proprietary drivers on Linux (though for now you'll need the proprietary drivers for some features like FreeSync, which is unfortunate but oh well).
I assume what you saw was the Nouveau driver, which is enough to have you up and running to be able to download the proprietary ones using GUI.
In fact, my graphics card (the cheapest to support Vista) is the only thing I haven't upgraded in the past 5+ years. And it was from eBay, used.
My graphics card supports the native UI elements of Windows.
My users don't want a "Save as" dialog with life-like water refraction and fog, rendered at higher FPS than their monitor.
Then you are in luck; even Intel GPUs under Linux do support OpenGL 4.5. 4.6 is in the works, the only missing part is the SPIR-V support and I don't suppose you need that for fluent or material design.
This works with open source drivers, it's only nvidia that is gumming up the works here. With recent drivers it should even be automatically setup, although you still need to set DRI_PRIME=1 when running something you want on the discrete GPU.