Slashdot Mirror


The Behind-the-Scenes Changes Found In MacOS High Sierra (arstechnica.com)

Apple officially announced macOS High Sierra at WWDC 2017 earlier this month. While the new OS doesn't feature a ton of user-visible improvements and is ultimately shaping up to be a low-key release, it does feature several behind-the-scenes changes that could help make it the most stable macOS update in years. Andrew Cunningham from Ars Technica has "browsed the dev docs and talked with Apple to get some more details of the update's foundational changes." Here are some excerpts from three key areas of the report: APFS
Like iOS 10.3, High Sierra will convert your boot drive to APFS when you first install it -- this will be true for all Macs that run High Sierra, regardless of whether they're equipped with an SSD, a spinning HDD, or a Fusion Drive setup. In the current beta installer, you're given an option to uncheck the APFS box (checked by default) before you start the install process, though that doesn't necessarily guarantee that it will survive in the final version. It's also not clear at this point if there are edge cases -- third-party SSDs, for instance -- that won't automatically be converted. But assuming that most people stick with the defaults and that most people don't crack their Macs open, most Mac users who do the upgrade are going to get the new filesystem.

HEVC and HEIF
All High Sierra Macs will pick up support for HEVC, but only very recent models will support any kind of hardware acceleration. This is important because playing HEVC streams, especially at high resolutions and bitrates, is a pretty hardware-intensive operation. HEVC playback can consume most of a CPU's processor cycles, and especially on slower dual-core laptop processors, smooth playback may be impossible altogether. Dedicated HEVC encode and decode blocks in CPUs and GPUs can handle the heavy lifting more efficiently, freeing up your CPU and greatly reducing power consumption, but HEVC's newness means that dedicated hardware isn't especially prevalent yet.

Metal 2
While both macOS and iOS still nominally support open, third-party APIs like OpenGL and OpenCL, it's clear that the company sees Metal as the way forward for graphics and GPU compute on its platforms. Apple's OpenGL support in macOS and iOS hasn't changed at all in years, and there are absolutely no signs that Apple plans to support Vulkan. But the API will enable some improvements for end users, too. People with newer GPUs should expect to benefit from some performance improvements, not just in games but in macOS itself; Apple says the entire WindowServer is now using Metal, which should improve the fluidity and consistency of transitions and animations within macOS; this can be a problem on Macs when you're pushing multiple monitors or using higher Retina scaling modes on, especially if you're using integrated graphics. Metal 2 is also the go-to API for supporting VR on macOS, something Apple is pushing in a big way with its newer iMacs and its native support for external Thunderbolt 3 GPU enclosures. Apple says that every device that supports Metal should support at least some of Metal 2's new features, but the implication there is that some older GPUs won't be able to do everything the newer ones can do.

2 of 205 comments (clear)

  1. Re:Metal 2? Idiocy by Anonymous Coward · · Score: 5, Interesting

    I'll say, as a game developer that has written a) OpenGL, b) Metal, and c) Vulkan renderers, I have no problems with Metal.

    A year since "release" and Vulkan is still half baked - we're up to sub point release FIFTY ONE. Sit down and write the basic Vulkan code required to just cope with the swapchain and get back to me. In 2 weeks. It will make you self harm.

    Metal is actually quite nice. They've hit a nice level of exposing power vs not making you have to fuck with every bloody register setting in the driver. The main problem is the Obj-C interface. Doing profiling and seeing how much time is eaten by obj_msgsend() will make you sad for a "high performance" API. But taking some time and making C++ shadow classes for some of this mitigates it.

    It's now a year since Google featured Vulkan at IO and the Android situation is the typical cluster fuck. We've done the work, but have no intention of shipping until Qualcomm (Adreno) and the Mali people make drivers that aren't hot garbage.

    Not an apple fanboy by any stretch (Want me to rant about xCode? Got a free week?) but uninformed people should stop constantly pushing for Vulkan without appreciating what a mess it is - especially on mobile. It will probably get there -- enough people are invested to make it happen. But it's not there yet.

    We're only a 15 months past initial release, and the extension fiasco that is OpenGL is starting in Vulkan...

  2. Re:Does APFS do away with "._" files? by TheRaven64 · · Score: 5, Informative

    Yes and no. Those ._foobar files don't appear on HFS+ either, they're only there for things like NFS or SMB shares or FAT filesystems that don't have the ability to store some of the metadata that Mac apps expect to work. The VFS layer transparently maps the metadata to and from these dot files when using a filesystem without the relevant metadata support. There are basically three solutions to this problem: silently lose the extra metadata (probably a bad idea), report an error to the program (which probably doesn't have handling for it) or store it somewhere else (which is ugly, but at least something that you can hide in the GUI). The ideal solution is for every (local and network) filesystem to support storing arbitrary metadata, but I don't know how we get from here to there.

    --
    I am TheRaven on Soylent News