For NetNewsWire for Mac, I get one or two crash logs a week referencing
scrollView:scrollWheelWithEvent:.
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.
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?
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.
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.
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:
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.
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.
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.
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.
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.
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.
Update (2020-02-06): lutaround:
Source is mixinglight.com the XDR is exhibiting some serious early signs of... marketing #apple #xdr #display #poor
Viewing angles are so bad that you get corner vignetting looking head on. That’s the most disappointing part to me. It messes with the light roll off and color even!
PCMag this week published its full review of the Pro Display XDR, doing a deep dive into its color accuracy and HDR capabilities.
[…]
In a nutshell, PCMag believes that the Pro Display XDR successfully does what it was meant to do, offer up “reference-quality production capabilities” to those who work on Macs. “The Pro Display XDR is a beautifully made, well-designed, hyper-accurate content creation monitor that--say it with me now--‘just works,’” reads the review.
Update (2020-02-14): Oliver Haslam:
Teoh has a great YouTube channel where he reviews displays and TVs, with technical analysis married with more subjective reporting. So when he turned his attention to Pro Display XDR I knew things could get interesting. And that’s exactly what happened when Teoh compared the display with Sony’s $43,000 monitor.
At first, you might think that’s unfair. Pro Display XDR might be costly at $4,999, but it’s a fraction of the cost of Sony’s own reference monitor. But this is the same monitor Apple called out at WWDC when it first announced Pro Display XDR. And it made a big song and dance about the new screen being “the world’s best pro display”. So, is it?
Update (2020-02-26): Craig A. Hunter:
Apple was kind enough to lend me a 28-core Mac Pro, decked out with a 2.5GHz Intel Xeon W (turbo boost to 4.4GHz) having a single 38.5MB L3 cache, 1MB L2 cache per core, 384GB of 2933MHz DDR4 ECC memory, a 4TB SSD, and two AMD Radeon Pro Vega II Duo 2x32GB graphics cards (each with two GPUs, for a total of four GPUs). Priced out on Apple’s website, this configuration goes for an eye-popping $31,199 ($10,800 of that is for the GPUs alone).
[…]
Whereas the iMac Pro tops out at 970 gigaflops with all 18 cores, the Mac Pro surpasses that level with just 13 cores and goes on to top out at 1.5 teraflops on 28 cores.
[…]
While running this test, all 28 cores were pegged at 100% for the full 42 minutes, but the Mac Pro’s fans never got loud, airflow never got excessive, and temperature stayed comfortable. The Mac Pro operated with a very quiet low frequency whoosh that is leagues ahead of similar workstations I have used, and would be well suited to an office environment.
Update (2020-02-28): Juli Clover:
As pointed out by MKBHD in a review published this morning, those super pricy wheels have no locking mechanism, which could be major problem if a wheel-equipped Mac Pro is placed on a desk or a slick floor.
Update (2020-03-12): Nilay Patel:
Because ultimately, that’s the story with the Mac Pro: the hardware is way, way ahead of software support. When we ran benchmark tests that pushed the GPUs, they turned in solid numbers, but so few apps were optimized to use Apple’s Metal graphics system that we basically never saw that performance in action during our day-to-day work.
[…]
In certain situations, the Mac Pro offered a clear speed boost by virtue of having so many more CPU cores than our other Macs, but you need apps that really take advantage of multithreading for that, and, well, Creative Cloud’s multithreaded performance is, at best, controversial. I mean, look, we tried to edit the video for this review on our Mac Pro using the full-res 4K video files in Premiere instead of lower-res proxies, and it dropped frames. That’s exactly the sort of thing Apple promotes the Mac Pro as being designed to overcome… if you’re using Final Cut Pro. You see the problem.
[…]
But in terms of bang for the buck, the PC trounced our Mac Pro. In nearly every benchmark save Premiere Pro playback tests, the PC came out ahead, and usually by significant margins. (We were not able to run After Effect benchmarks because the test suite gave us errors on the Mac Pro. Catalina!)
Update (2021-04-15): Sami Fathi:
Apple has adjusted the marketing of its high-end Pro Display XDR in the UK following complaints to the country’s Advertising Standards Authority that it was misleading customers.
[…]
Apple previously marketed the Pro Display XDR as featuring P3 wide color gamut without any caveats, however following the complaint, the company has added a footnote to the product page in the UK to indicate it “supports 99% of the P3 wide color gamut.”
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’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.
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:
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.
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.
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.
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.
Update (2020-02-06): Jimmy Grewal:
I designed the MacIE 5 toolbar customization feature and was surprised when I saw the same implementation a year later in Mac OS X 10.0. Though @siracusa described it as “shamelessly reminiscent” of MacIE 5, I’m happy that it lives on in macOS and iOS.
