Archive for January 6, 2020

Monday, January 6, 2020 [Tweets] [Favorites]

Mystery Scrollwheel Crash

Brent Simmons:

For NetNewsWire for Mac, I get one or two crash logs a week referencing scrollView:​scrollWheelWithEvent:.

Here’s the bug for it.

I’ve been getting these crashes in my app, too, but only on macOS 10.14. On previous macOS versions, the app is not using responsive scrolling. And I’ve yet to see this crash from anyone using macOS 10.15. I’ve never seen it on my Macs.

Beware Spinlocks in User Space

Malte Skarupke (via Shantonu Sen, Niels Broekhuijsen):

I overheard somebody at work complaining about mysterious stalls while porting Rage 2 to Stadia. […] The only thing those mysterious stalls had in common was that they were all using spinlocks. I was curious about that because I happened to be the person who wrote the spinlock we were using. The problem was that there was a thread that spent several milliseconds trying to acquire a spinlock at a time when no other thread was holding the spinlock. Let me repeat that: The spinlock was free to take yet a thread took multiple milliseconds to acquire it. […] In our case we were able to make the problem go away by replacing spinlocks with mutexes, but that leads to the question: How do you even measure whether a spinlock is better than a mutex, and what makes a good spinlock?

Linus Torvalds (Hacker News):

So now you still hold the lock, but you got scheduled away from the CPU, because you had used up your time slice. The “current time” you read is basically now stale, and has nothing to do with the (future) time when you are actually going to release the lock.

Somebody else comes in and wants that “spinlock”, and that somebody will now spin for a long while, since nobody is releasing it - it’s still held by that other thread entirely that was just scheduled out. At some point, the scheduler says “ok, now you’ve used your time slice”, and schedules the original thread, and now the lock is actually released. Then another thread comes in, gets the lock again, and then it looks at the time and says “oh, a long time passed without the lock being held at all”.

[…]

You’re just getting random values because different schedulers have different heuristics for “do I want to let CPU bound processes use long time slices or not”?

[…]

Notice, how when the author uses an actual std::mutex, things just work fairly well, and regardless of scheduler. Because now you’re doing what you’re supposed to do. Yeah, the timing values might still be off - bad luck is bad luck - but at least now the scheduler is aware that you’re “spinning” on a lock.

Malte Skarupke:

Once we break it down like that we realize that actually these are all the same case. In all of these cases one thread can run, all others are calling yield(). The only difference between the case that I wanted to measure and the other two accidental cases is whether the scheduler is incorrectly not running thread C or incorrectly not running thread N. In either case all other fifteen threads are just calling yield().

So your claim is that it’s a problem that I try to measure how long it takes for thread N to run even though I might accidentally be measuring how long it takes for thread C to run. But I claim that that’s fine because these are all equally problematic. One thread could run, all other threads are yielding, yet that one thread is not running. And we don’t care whether the thread that could run is thread N or thread C.

Linus Torvalds:

The problem with that is “yield” is pretty much undefined. The definition of it is literally about single queue of a real-time behavior with a real-time scheduler with priorities.

[…]

What you want to use it for is “schedule the right process”. But you don’t even know what the right process is, or if you do you don’t tell the system (because sched_yield() literally doesn’t have that interface), so the kernel has to guess.

Previously:

Testing the 2019 Mac Pro and Pro Display XDR

Lloyd Chambers:

Thus my updated advice is to buy ONLY a 16-core (or 24/28 core if warranted). An 8-core or 12-core Mac Pro is marginal in terms of CPU performance relative to the 2019 iMac 5K.

My testing shows that for single-threaded stuff, a CPU core in the 16-core 2019 Mac Pro is up to 30% slower per core than the 2019 iMac 5K.

gravitycore:

I’m an app developer/designer and recently got a new mac pro for my business and wanted to see how it stacked up with my other machines. The results are interesting; the Mac Pro does not do so hot when making clean compiles, but does deliver consistently faster incremental builds.

[…]

It seems the best bang for your buck right now when it comes to compiling projects is the Mac mini. I’m certainly disappointed in the Mac Pro results, especially since it seems that Xcode completely pegs all the 16 cores during a compile, but even at 3.2GHz fails to outperform a 3.0 GHZ i5 with 6 cores.

Note that these tests were performed with Xcode 10.3 rather than Xcode 11.

Juan Salvo:

For folks considering the Apple Pro XDR monitor as a reference screen. Here is it, side by side with a couple of actual reference monitors.

[…]

Like the 310K the XDR uses local dimming zones. 576 of them to be exact. So a grid of 32x18. Now there’s a lot of factors to how effectively they zone. But 576 is not very many zones and the result is that you can clearly see the haloing.

Previously:

Update (2020-01-07): Mike Rundle:

At the XDR display introduction event, Apple did go out of their way to compare it to reference monitors that cost $30-50K, so this is a fair comparison.

Vitaly Ishkulov:

Apple’s 1:1,000,000 contrast ratio on the new Pro Display XDR. It’s just a white line on a black canvas. Also see the glow around the perimeter of the canvas.

Update (2020-01-10): Quinn Nelson:

I’ve only been using the ProDisplay XDR for a day, but I’m getting pretty extreme color and light roll-off in all four corners of the display. Almost like vignetting. When I readjust my head it’s fine, but viewing angles on this monitor are not very good which is disappointing.

I will say however that even though I didn’t opt for the +$1,000 matte option, this “glossy” option is very much not glossy. The glare is unbelievably low and makes my iMac Pro look like a mirror. I hope Apple brings this across the entire Mac lineup. It’s awesome.

Quinn Nelson:

I, for one, am glad that Apple doesn’t include the Pro Stand in the price of the ProDisplay XDR (as many have said Apple should have done) because I don’t think it’s actually a very great stand and anybody buying the monitor should VESA mount it instead.

Quinn Nelson:

Tilt doesn’t lock to perfect 180 deg and the tilt radius is not even. Tilts way more to the left than to the right. No height adjustability in vertical position sucks. No axis control.

No Home Videos in TV App

Jeff Richardson:

I found the solution after digging around for a while on Apple’s online support discussions.  It turns out that in iOS 10.2, you need to install something that you bought from iTunes before you can watch something that you transferred from a computer.  This is obviously a bug, but there is a work-around that you can use until Apple fixes this.  If you go to the bottom of the TV app and tap on the Store icon, you can scroll to the bottom to see buttons to press that will let you buy content from iTunes.  I recommend that you tap Free Episodes.  That opens up the iTunes app, and if you download anything — including something that is free — the TV app works.

[…]

Finally, I noticed that after I added more movie content to the iPhone, I would sometimes have to force quit the TV app and launch it again to see the additional downloaded content.

I tried this, but like some other users, I was never able to get it to work. iTunes says that the videos are on the iPhone, but they don’t show up and can’t be played. I eventually gave up and used iTunes to manually transfer them to the VLC app.

Previously:

Chrome OS Has Stalled Out

David Ruddock (Hacker News):

Chrome’s problems really became apparent to me when Android app compatibility was introduced, around five years ago. (This also isn’t the first time we’ve pointed out that approach’s failings, Corbin did so in an editorial last year.) Getting Android apps to run on Chrome OS was simultaneously one of the Chrome team’s greatest achievements and one of its worst mistakes. In 2019, two things are more obvious than ever about the Android app situation on Chrome. The first is that the “build it and they will come” mantra never panned out. Developers never created an appreciable number of Android app experiences designed for Chrome (just as they never did for Android tablets). The second is that, quite frankly, Android apps are very bad on Chrome OS. Performance is highly variable, and interface bugs are basically unending because most of those apps were never designed for a point-and-click operating system. Sure, they crash less often than they did in the early days, but anyone saying that Android apps on Chrome OS are a good experience is delusional.

[…]

I say this even as one of the few people who can do 95% of my job on a Chromebook: that 5%, when you really, really need it, is more than enough reason to avoid a platform entirely. And for many others, it’s much more than 5%: it’s their entire workflow.

John Gruber:

The existence of the “Chrome OS can run Android apps” crutch has stunted Google’s motivation to push the platform forward to solve the remaining tasks that the platform isn’t suited for in ways that are truly native to Chrome.

Previously:

20 Years Ago: Internet Explorer 5 and iTools

Jimmy Grewal (thread):

Today marks the twentieth anniversary of the introduction of Microsoft’s Internet Explorer 5 for Mac. This was both the most important release of Internet Explorer for the Mac, and the last release.

[…]

The standards compliant rendering engine for MacIE 5 was not shared with the Windows version. It was a new, independent code base designed from the ground up by @t and @sfalken to handle both existing web content and newer standards compliant content.

[…]

The UI of MacIE 5 was a major departure from any existing MS product, or for that matter any Mac software. Microsoft engineer @MafVosburgh hired UK based Nykris to design the iMac inspired “new look” as it was called internally. […] This “new look” had an uncanny resemblance to Apple’s later Aqua interface for Mac OS X. However it was developed in complete secrecy within Microsoft. When we previewed MacIE 5 with the “new look” to Apple in the Summer of 1999, Jobs was not pleased.

[…]

Media Toolbar was based on code licensed from the developers of SoundJam MP, a popular MP3 player. Unbeknownst to us, Steve Jobs too had his eye on SoundJam and it’s lead developer Jeff Robbin. Jobs insisted we cut this feature claiming it undermined QuickTime.

[…]

Traditionally, a Microsoft exec would come on stage to unveil and demo our products. In this case, Apple’s insisted that Jobs would do the demo himself. Talking points were agreed, but much to our dismay Jobs didn’t mention a single one.

I really liked Internet Explorer 4.5 for Mac OS 9. It rendered well and quickly and had a good user interface. Version 5 for Mac OS X also worked well, but the faux-Aqua interface and toolbar buttons never felt right to me, and—like nearly everything with 10.0—it felt slow.

Cabel Sasser:

I was a huge IE Mac fan. When they introduced support for .png with alpha — maybe the first browser to do so? — I built a DHTML (lol) Audion Face previewer that let you drag around the faces on our web page, and that really blew a lot of minds.

Bill Davis:

Apple’s original internet strategy turns 20 today. Who remembers iTools? I still use my mac.com email that I set up on January 5, 2000.

Update (2020-01-07): John Gruber:

What struck me about this demo is Jobs’s attention to minor UI details — like the fact that the Carbon IE 5 app used the same Aqua scrollbars as a Cocoa app. The pace and conversational tone — and the assumption that everyone watching cares as much as Jobs himself does about nitty-gritty UI details — feels very unlike a modern day Apple software demo. It’s easy to get sucked into the whole video, but the unveiling and demo of Apple Mail that follows has that same thing going for it.

Maf Vosburgh:

I devised and coded the Mac IE 5 media toolbar in the second half of 1999. The toolbar could stream music playlists or play video in a floating movie window, while you browsed the web. It had a lovely UI designed by Nikki Barton. It was cool.

Initially I got it working with QuickTime Streaming and then I got indie developer Jeff Robbin to write me a custom plugin to add support for SHOUTcast stream and decode (MP3 over HTTP), using bits of existing code from his app SoundJam. This was all working in 1999.

[…]

The weird thing is that the whole feature was basically a love letter to QuickTime Streaming with open standard SHOUTcast as an after-thought. The people up in Redmond wanted us to be implementing Video for Windows support instead and we didn't want to because we were Mac heads.