Hacker News new | ask | show | jobs
by eatsfoobars 3737 days ago
A response from a Google engineer working on Chrome: https://medium.com/@slightlylate/cards-on-the-table-i-m-an-e...
2 comments

Great response. A couple key points:

-The author was comparing an unreleased version of Safari to Chrome Stable. Comparing stable-to-stable would be more fair, and when comparing the unreleased Safari to Chrome Dev or Canary, some of their complaints are moot.

-Apple only has to support 2 platforms and a limited amount of hardware. Google supports 4+ platforms and a huge variety of hardware. That means things like GPU rasterization take longer to ship.

Apple has to support 4 different GPU manufacturers, in fact. And Chrome isn't using the native Direct2D on Windows, which would have made this easier: rather they chose to reinvent it with Ganesh. Ganesh is OpenGL only (also Vulkan) instead of using native Direct3D. I don't think the cross-platform burden is that much higher for Chrome in this specific area.
That's hardly accurate summary of the situation.

Chrome uses Skia, a 2D rendering library.

Skia uses Direct2D (DirectWrite) on Windows for font rendering (https://github.com/google/skia/blob/master/src/ports/SkTypef...)

Skia has a GPU backend that uses OpenGL where that's native.

On Windows, those OpenGL calls are translated to DirectX with a very sophisticated OpenGL translator called Angle (https://github.com/google/skia/blob/master/gyp/angle.gyp)

Therefore Chrome does use DirectX on Windows, via translation layer from OpenGL.

Saying that Chrome i.e. in this context Skia, doesn't use Direct2D for rendering is like saying "On Windows Chrome doesn't use native Chakra JavaScript engine".

Skia IS Direct2D, except it's cross-platform and being improved by Google literally every day (https://github.com/google/skia/commits/master). It makes engineering sense for Google to have their own, cross-platform, high-performance 2d rendering engine instead of a thin layer of whatever the common-denominator they could implement on top of 2d functionality provided by the OS.

I wasn't aware of the use of DirectWrite, thanks.

> On Windows, those OpenGL calls are translated to DirectX with a very sophisticated OpenGL translator called Angle (https://github.com/google/skia/blob/master/gyp/angle.gyp)

I'm aware of that. But ANGLE can't possibly be better than Direct3D; in fact, it tends to lag behind new D3D releases for obvious reasons.

> Saying that Chrome i.e. in this context Skia, doesn't use Direct2D for rendering is like saying "On Windows Chrome doesn't use native Chakra JavaScript engine".

Yet that's still a true statement. And if Chakra were technically ahead of V8, then that would be a valid criticism of Chrome's choice here.

> It makes engineering sense for Google to have their own, cross-platform, high-performance 2d rendering engine instead of a thin layer of whatever the common-denominator they could implement on top of 2d functionality provided by the OS.

I don't think that's clear at all. Direct2D is very good for what it is (although neither Skia nor D2D is a good API for GPUs really, as NVIDIA and others have pointed out in for example [1]). There's no architectural advantage that Skia has over D2D; they both feature very similar immediate mode APIs. D2D is being improved by Microsoft all the time, with a multi-year head start on Ganesh and the advantage of tight integration with the graphics drivers. In fact, the entire point of Alex's post is to acknowledge that Ganesh's rollout has been slower than that of CG::OGL (Apple's Ganesh equivalent, which has been shipping in stable Safari for a while) and Direct2D (which has been shipping in IE since 9 and Firefox since 4).

[1]: http://developer.download.nvidia.com/devzone/devcenter/gameg...

This response is interesting. The engineer attempts to differentiate the philosophy behind chromes feature prioritization as being due to their desire to implement features in a manner that conforms with the ideals behind the "extensible web" manifesto.

But there is a sense to which "extensible web" focused engineering is inherently at odds with a desire to contain browser complexity and to prioritize the security, performance, and stability of the average web site browsing experience across platforms.

My general experience with using the web these days (with any browser) is that on average sites I visit seem:

1. More broken 2. Slower 3. More invasive

There's definitely an extent to which this is "not browser makers fault, this is the fault of site developers" -- however to completely abdicate platform vendors responsibility and say that it's not a requirement for browser technology to solve is to (potentially) watch the whole web platform erode to the point where it is no longer sufficient to satisfy users needs. In a way it's balmer on stage chanting "developers developers developers" vs jobs in a drum circle meditating "users users users". Not that I necessarily think Safari is the best drum circle development example -- I'm more tempted by "brave".