261–270 of 342 posts
Earlier quoted context omitted.
Activity Monitor is not a reliable way to inspect memory usage, it's optimized for speed of calculation. Use 'footprint' and 'zprint' or Xcode/Instruments instead.
Activity Monitor measures memory footprint.
Earlier quoted context omitted.
Browsers and other players will generally be fine, as they render the image progressively. However, editors /processing tools which attempt to load it as a series of frames or a video will usually break, as memory consumption explodes, unless they have a smart disk buffer system to handle it. I wouldn't be surprised if some poorly implemented players were built on top of abstraction layers that end up flattening the…
And this kids, is why we have key and delta frames. We should drop gif support.
We just need an actual replacement that has the same behaviours and actually works everywhere, as gif does. Videos are not a replacement, and other image formats don't work everywhere
Earlier quoted context omitted.
It makes about as much sense as calling humans "lactating fish"
Where the category "fish" isn't a clade - it's possible to evolve to no longer be a fish - it's more comparable to a specific generation of ARM chips, like perhaps ARM32, than it is to the ARM line in general. It would be weird to say "64-bit ARMv5" in the same way that it would be weird to say "lactating fish". But it is not weird to say "64-bit ARM" for the same reason it isn't weird to say "lactating euteleostome.…
Earlier quoted context omitted.
I think this is because video codecs superseded everything else. An MP4 file is going to be roughly the same size as an apng, while enjoying hardware acceleration on a lot of devices out there. There's still the weird niche of lossless compression where apng or webp would be preferred.
20 years ago the case was stronger but video codecs have both soaked up the performance wins and do not expose new security exposure. Based on APNG and JPEG 2000, the only question I have for new formats is how they plan to get browser support. It’s a hard path to relevance unless you have a good answer for that (even if it’s, say, a WASM fallback).
Earlier quoted context omitted.
And this kids, is why we have key and delta frames. We should drop gif support.
> We should drop gif support. We just need an actual replacement that has the same behaviours and actually works everywhere, as gif does. Videos are not a replacement, and other image formats don't work everywhere
Chrome, Firefox, Edge, Android, and iOS. That covers most of what we want, right? It fails on say... a 2009 era netbook or Android Gingerbread, but we gotta draw the line somewhere.
Even if you do care about Android Gingerbread: H264 3.0 Baseline profile IIRC worked on that (though its been a decade, so maybe I'm getting version numbers mixed up...). Going back to H.264 3.0 Baseline would reduce your compression-efficiency (more distortion / noise at same filesize, or larger filesize for same levels of distortion), but greatly improve your compatibility with decade-old devices if you cared.
Even H.264 3.0 Baseline is a far superior format compared to GIF though.
-------------
Lol audio is a mess though. But video-only is actually way better than most people expect.
Earlier quoted context omitted.
The original Apple I / II before the Macintosh used the MOS 6502 processor.
6502 is arguably a "proto-ARM", so one could say Apple has come full circle.
Earlier quoted context omitted.
It hasn't been debunked if there's no source for the claim...
Apple said that the kernel interface used by smartctl is emitting invalid data, which invalidates all conclusions drawn from it, such as “there is/isn’t a problem with SSD wear”.
I compared smartctl output with activity monitor on disk writes and it's exactly the same number. You can do the same.
There’s more information, including a copy of the image, in the forum discussion. The forum seems a bit pokey for me at the moment, though. https://forums.flyingmeat.com/t/memory-consumption-when-open... Gus Mueller (the author of the linked tweet) is the author of the Acorn image editor.
Thanks for the link. The issue seems to be the IOAccelerator framework: > I’ve narrowed it down quite a bit (and submitted it to Apple as FB9112835). > What’s going on is that the IOAccelerator framework has some sort of massive leak in it, where it’s using up 35GB of ram, 25 of which is going to swap (which is why you’re seeing kernel_task flake out). > On intel, the same image only uses 1480K from IOAccelerator.
Earlier quoted context omitted.
> We should drop gif support. We just need an actual replacement that has the same behaviours and actually works everywhere, as gif does. Videos are not a replacement, and other image formats don't work everywhere
H.264 level 4.0 seems to have similar behaviors and works on a very wide variety of platforms in my experience. Chrome, Firefox, Edge, Android, and iOS. That covers most of what we want, right? It fails on say... a 2009 era netbook or Android Gingerbread, but we gotta draw the line somewhere. Even if you do care about Android Gingerbread: H264 3.0 Baseline profile IIRC worked on that (though its been a decade, so may…
edit: grammar
Earlier quoted context omitted.
Apple said that the kernel interface used by smartctl is emitting invalid data, which invalidates all conclusions drawn from it, such as “there is/isn’t a problem with SSD wear”.
Can you provide a link please? I compared smartctl output with activity monitor on disk writes and it's exactly the same number. You can do the same.
> "While we're looking into the reports, know that the SMART data being reported to the third-party utility is incorrect, as it pertains to wear on our SSDs" said an AppleInsider source within Apple corporate not authorized to speak on behalf of the company. The source refused to elaborate any further on the matter when pressed for specifics.
We'll likely never hear anything else about this again from Apple officially or unofficially, so I don't expect anyone who believes there's an SSD wear issue to stop believing that there is. Either the combination of "smartmontools is emulating SMART access, but doesn't actually have it" and "a source at Apple said that smartmontools is incorrect" is enough to make this a non-issue, or it's not — and since most people who think that there is a wear issue don't realize the part about smartmontools faking that it has access to SMART data in this scenario (hint: nope!), I don't expect to find common ground.
So as far as I'm concerned, this is all irrelevant until someone's SSD wears out, and no one's reported that, so everyone is all tempest-in-a-teapot over some numbers that an open source tool is handcrafting from a macOS kernel API based on assumptions about Apple's proprietary hardware that are probably wrong. Wake me up when someone's SSD wears out.