Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebKit Goals for 2020

trac.webkit.org

Post reply on HN
Print view View original

131–140 of 154 posts

Re: WebKit Goals for 2020

#131

Post by om2 »

lern_too_spel wrote: post #118
saagarjha wrote: post #102

Earlier quoted context omitted.

> start outperforming your competition instead of merely banning your competition FWIW, Safari generally outperforms competing browsers on benchmarks.

By using undocumented MacOS private APIs, which bolsters his point. On OSes that don't have this issue, other browsers perform better on the same hardware. https://mozillagfx.wordpress.com/2019/10/22/dramatically-red... This has been going on since WebKit launched with no effort from Apple to clean it up, so it certainly seems intentional. http://archive.is/MtntN

CoreAnimation is not a private API. Everything directly mentioned in that post is public API. Firefox may use private API but it’s not mentioned in the post.

Re: WebKit Goals for 2020

#132

Post by lern_too_spel »

om2 wrote: post #131
lern_too_spel wrote: post #118

Earlier quoted context omitted.

By using undocumented MacOS private APIs, which bolsters his point. On OSes that don't have this issue, other browsers perform better on the same hardware. https://mozillagfx.wordpress.com/2019/10/22/dramatically-red... This has been going on since WebKit launched with no effort from Apple to clean it up, so it certainly seems intentional. http://archive.is/MtntN

CoreAnimation is not a private API. Everything directly mentioned in that post is public API. Firefox may use private API but it’s not mentioned in the post.

"It’s worth noting that the ability to assign an IOSurface to the CALayer contents property is not properly documented."

Re: WebKit Goals for 2020

#133

Post by om2 »

lern_too_spel wrote: post #132
om2 wrote: post #131

Earlier quoted context omitted.

CoreAnimation is not a private API. Everything directly mentioned in that post is public API. Firefox may use private API but it’s not mentioned in the post.

"It’s worth noting that the ability to assign an IOSurface to the CALayer contents property is not properly documented."

Contents property itself is not a private API. Quality of docs I can't speak to, but it's a different issue than private API (which is stuff that's not in the public SDK).

Re: WebKit Goals for 2020

#134

Post by The_rationalist »

Razengan wrote: post #126
The_rationalist wrote: post #90

It's fascinating to see how pathetic this roadmap is. The totality (100%) of their planned features are already available on chromium. Guess what, even after that the chromium of today (not 2020) still has an order of magnitude more features, optimisations and testing. In human hours wise, comparing the number of full-time safari developers vs the number of full-time chromium (Google, Microsoft, opera, etc) developer…

> Apple should just be rational and make the same synergistic move as Microsoft: migrate to chromium. It would save them R&W (reinventing the wheel) money, and they could allocate it to true R&D, allowing the web to move forward for making the world a better place. Chromium is a descendant of WebKit in the first place... > With such absurd politics, I wonder how Apple survived through history. Because users agree wit…

Chromium is a descendant of WebKit in the first place... And safari is a descendant of KHTML, double standard I guess? The world change.

Re: WebKit Goals for 2020

#135

Post by The_rationalist »

hirsin wrote: post #128
The_rationalist wrote: post #90

It's fascinating to see how pathetic this roadmap is. The totality (100%) of their planned features are already available on chromium. Guess what, even after that the chromium of today (not 2020) still has an order of magnitude more features, optimisations and testing. In human hours wise, comparing the number of full-time safari developers vs the number of full-time chromium (Google, Microsoft, opera, etc) developer…

Note that the logged in API is not supported in Chrom(e|ium). That WI be a big deal when finished because it will help with user privacy without breaking things.

Interesting to know, but they could develop this feature inside chromium so it is a moot point. Moreover features only supported by safari will be used by exactly 0% of web developers.

Re: WebKit Goals for 2020

#136

Post by ksec »

pornel wrote: post #99
cordite wrote: post #11

I'm glad that battery life is a top priority. Though WebP would still be nice to have..

Apple already has HEIC codec on their systems, which is half the size of WebP. I'm curious why they're not exposing it to the Web. Is it because the codec is a ball of risky C++ code? Patent issues? Or because it's non-standard, and for once, they don't want to add a non-standard feature? There's also JPEG XL being standardized now, which gives similar compression while also supporting lossless conversion from the cl…

> Patent issues?

As far as I am aware HEVC issues is still not fully resolved. And likely unfit for Web usage.

Re: WebKit Goals for 2020

#137

Post by lern_too_spel »

om2 wrote: post #133
lern_too_spel wrote: post #132

Earlier quoted context omitted.

"It’s worth noting that the ability to assign an IOSurface to the CALayer contents property is not properly documented."

Contents property itself is not a private API. Quality of docs I can't speak to, but it's a different issue than private API (which is stuff that's not in the public SDK).

The second link has private APIs, and the header file to access those private APIs still exists in WebKit for MacOS. I mentioned both undocumented and private. The first link just shows that if you are Apple, you can correctly call APIs that provide a performance increase on MacOS.

Because of that, my recommendation is to just stop using MacOS if you care about browser performance.

Re: WebKit Goals for 2020

#138

Post by saagarjha »

lern_too_spel wrote: post #137
om2 wrote: post #133

Earlier quoted context omitted.

Contents property itself is not a private API. Quality of docs I can't speak to, but it's a different issue than private API (which is stuff that's not in the public SDK).

The second link has private APIs, and the header file to access those private APIs still exists in WebKit for MacOS. I mentioned both undocumented and private. The first link just shows that if you are Apple, you can correctly call APIs that provide a performance increase on MacOS. Because of that, my recommendation is to just stop using MacOS if you care about browser performance.

> The second link has private APIs

Private APIs which were used back in 10.4 when NSAppKitVersionNumberWithDeferredWindowDisplaySupport (documented here https://developer.apple.com/documentation/appkit/nsappkitver...) was not available.

> the header file to access those private APIs still exists in WebKit for MacOS

The most these headers can do is maybe help with rendering performance, of which I'm not completely certain that there are still APIs that Safari uses that other browsers don't. I cannot see how benchmark scores from e.g. JavaScriptCore would be affected.

> Because of that, my recommendation is to just stop using MacOS if you care about browser performance.

Your point doesn't logically follow.

Re: WebKit Goals for 2020

#139

Post by lern_too_spel »

saagarjha wrote: post #138
lern_too_spel wrote: post #137

Earlier quoted context omitted.

The second link has private APIs, and the header file to access those private APIs still exists in WebKit for MacOS. I mentioned both undocumented and private. The first link just shows that if you are Apple, you can correctly call APIs that provide a performance increase on MacOS. Because of that, my recommendation is to just stop using MacOS if you care about browser performance.

> The second link has private APIs Private APIs which were used back in 10.4 when NSAppKitVersionNumberWithDeferredWindowDisplaySupport (documented here https://developer.apple.com/documentation/appkit/nsappkitver... ) was not available. > the header file to access those private APIs still exists in WebKit for MacOS The most these headers can do is maybe help with rendering performance, of which I'm not completely ce…

> Private APIs which were used back in 10.4 when NSAppKitVersionNumberWithDeferredWindowDisplaySupport (documented here https://developer.apple.com/documentation/appkit/nsappkitver...) was not available.

And private APIs that still aren't available, as I noted in the second section you responded to.

> The most these headers can do is maybe help with rendering performance

Exactly. Everything I referenced was about rendering performance. I never claimed otherwise, so don't derail the argument by strawmanning JavaScriptCore vs. V8 on MacOS.

> Your point doesn't logically follow.

If you want the most speed, you want to use a platform that gives everyone access to APIs that enable it. QED.

Re: WebKit Goals for 2020

#140

Post by millstone »

lern_too_spel wrote: post #129
millstone wrote: post #124

Earlier quoted context omitted.

What is this hope for healthy browser engine competition? On Android and ChromeOS, Chrome and Chromium-based browsers have more than 99% marketshare. "Apple should allow non-WebKit browsers" is really saying "what's holding back the mobile web is that Google does not completely dominate it." Only one thing prevents that outcome today.

That's a novel argument against allowing competing browsers. Let's apply a basic check on its validity. Do you think Mozilla agrees with it? I think you'll find the answer is "no." Not allowing competing browsers does not help the web ecosystem or the users. It helps only Apple.

Yes I think Mozilla would agree with both the marketshare figures, and that iOS is the only effective check on Google's mobile web dominance.

How has allowing competing browser engines on Android helped the web ecosystem? Non-Chromium browsers are a rounding error on Android.

Post reply on HN