Live data from Hacker News

The irony of Apple homepage and Safari WebP support

mobilerank.co

61–70 of 75 posts

Re: The irony of Apple homepage and Safari WebP support

#61
post #35
post #19

That is to save 146KB on one image an 99KB on another, to save 2 seconds you'd have to using a 1mbps connection. The first random internet article I pulled for real world cellular speeds suggests even unwired, people are getting 30mbps so that changes the article to: Apple could load 66ms faster by adopting WebP … but these are cached resources, so maybe… Apple could perform the initial load 66ms faster by adopting W…

1) “real world” cellular speeds at 30mbps? That sounds ludicrous to me. Maybe in America, definitely not in many countries across the world. 2) I don’t know a lot of people who are repeat visitors to apple.com. Mentioning the fact that the time is initial load time would be redundant.

> Maybe in America I'd say maybe outside America. Our cell service is pretty terrible if you leave major metropolitan areas, or if you try to actually use your "unlimited" data.

Re: The irony of Apple homepage and Safari WebP support

#62
post #17

At this point, I don't think it's too fringey a conspiracy theory that Apple is opposed to the advancement of web technology, while trying to plausibly appear to be in favor of it. Their motive would be obvious. Keep the native app experience superior.

They're also financially benefiting by pushing competing HEIC and HEVC formats since they're patent owners and collect royalties for big scale implementations. In light of that, it's not surprising they refuse to support royalty free formats.

Apple supports formats they can hardware accelerate. They have historically picked one format to accelerate in hardware (H.264, now its HEVC), and pay the royalties with the format they pick.

Re: The irony of Apple homepage and Safari WebP support

#63
post #17

Earlier quoted context omitted.

They're also financially benefiting by pushing competing HEIC and HEVC formats since they're patent owners and collect royalties for big scale implementations. In light of that, it's not surprising they refuse to support royalty free formats.

Apple supports formats they can hardware accelerate. They have historically picked one format to accelerate in hardware (H.264, now its HEVC), and pay the royalties with the format they pick.

Apple SoCs have VP9 hardware acceleration support already and they still won't support them to push HEVC.

Also there's no reason for them not to HW accelerate WebP with the same system (the frames are compatible) but they chose not to, so I'm not quite sure what your point here is.

Re: The irony of Apple homepage and Safari WebP support

#64
post #51
post #17

Earlier quoted context omitted.

They're also financially benefiting by pushing competing HEIC and HEVC formats since they're patent owners and collect royalties for big scale implementations. In light of that, it's not surprising they refuse to support royalty free formats.

Apple would paid more for HEVC royalty than they receive, or a break even. I doubt royalty payment is an incentive of any kind to Apple. But much rather patent protection.

I work in video streaming business and I haven't seen anything to support this (if anything, they were exempt from royalties from their own patent pool), can you please link something that confirms this?

Re: The irony of Apple homepage and Safari WebP support

#65

This is only one half of the story. Given the increased network bandwidth, decoding speed matters. And here, JPEG is much faster. Also note that the JPEG decompression algorithms are highly optimized and coded in assembly language, and there are maybe even hardware decoders. On android: WebP 66% less file size than JPG, 267% more time to decode. WebP 38% less file size than JPG, 258% more time to decode. WebP 89% les…

On Android, JPG decoder lib may or may not use a DSP on Qualcomm SoCs, WebP doesn't have any hardware decoding support.

Any size gains will be much more noticeable in the context of network transmission.

Re: The irony of Apple homepage and Safari WebP support

#67

Earlier quoted context omitted.

Easily explained! Apple prefers you to use native widgets to make your app harder to port.

That argument could be used for Qt, GNOME, macOS, or Windows. And besides, React Native is a thing.

Qt and GNOME are released by an organization that also maintains a popular browser. Microsoft recently chromified their flagship browser (despite my personal feelings on the matter). I could be wrong, but I don't think React Native gets any support from Apple.

Re: The irony of Apple homepage and Safari WebP support

#68
post #19

That is to save 146KB on one image an 99KB on another, to save 2 seconds you'd have to using a 1mbps connection. The first random internet article I pulled for real world cellular speeds suggests even unwired, people are getting 30mbps so that changes the article to: Apple could load 66ms faster by adopting WebP … but these are cached resources, so maybe… Apple could perform the initial load 66ms faster by adopting W…

The other question is -- how does it affect battery life? New codecs usually take more CPU.

Re: The irony of Apple homepage and Safari WebP support

#69

Could anyone one please tell me what is the purpose of the Web Notifications, other than invasive marketing.

I guess you have some notifications on your phone, right? That's the point, notifications for things. If someone sends you a text then you need a notification so you actually notice it.

Re: The irony of Apple homepage and Safari WebP support

#70

Firstly, i don't get what apple has to gain by not supporting webp... Nevertheless: The screenshot puzzles me, it shows two assets, and states that compressing these by an extra ~ 250 kb would save 2 seconds. Maybe on very slow connections? Also > Lack of proper support for [...] web notifications on mobile I can do without these i guess

"i don't get what apple has to gain by not supporting webp"

I am not totally savvy as to the difficulty of the feat but, at least in principle, would it not cost them less in time and maintenance to not implement or support a feature?

Post reply on HN