
Google Earth Ported to Browsers with WebAssembly - nfrankel
https://www.infoq.com/news/2019/06/google-earth-web-assembly-port/
======
dgaudet
the article seems to suggest that this is a port of the original (not web)
google earth app to webassembly ... but what i'm seeing is another version of
the web app. the desktop app has a zillion more features which are not
available in the web app... aside from the similarity of their name, and the
shared imagery, the two are completely different things. i'm bummed, i was
hoping the desktop app was being given a breath of fresh air. it's one of the
most important tools i use for planning hikes on infrequently climbed
mountains.

~~~
nacs
As the article mentions, this is a port of the previously-Chrome-only NaCL-
powered version of Google Earth.

I doubt the web-based versions (whether JS/WebAssembly/Nacl, etc) will ever
have the feature-set of the standalone Google Earth (nor is there much
monetary reason for Google to do so).

~~~
mtgx
Hopefully this means Google will attempt to use CPUs from vendors other than
Intel on new Chromebooks. I imagine the handful or so of NaCL (not PNaCL) apps
were the reason why they supported Intel CPUs on Chromebooks so much.

~~~
grapeli23
[https://www.chromium.org/chromium-os/meltdown-spectre-
vulner...](https://www.chromium.org/chromium-os/meltdown-spectre-
vulnerability-status)

In this list, I see more than 40 ARM-based models. This is very, very much
compared to the list of commercially available M$ Surface. In comparison with
the number of Android devices it's a drop in the sea.

------
Ajedi32
Original blog post by Google: [https://blog.chromium.org/2019/06/webassembly-
brings-google-...](https://blog.chromium.org/2019/06/webassembly-brings-
google-earth-to-more.html)

------
lmkg
I would be extremely interested to hear a report or post-mortem of the porting
process. The fact that a decade-old, resource-intensive C++ program can be
ported successfully speaks well to WebAssembly living up to its potential.
Knowing what went well, what went pear-shaped, caveats, gotcha's, etc with
this project would start building up the "community knowledge" about whether,
when, and how other code bases could be ported.

~~~
chhum
I was pretty blown away by this talk
[https://www.infoq.com/presentations/autocad-
webassembly/](https://www.infoq.com/presentations/autocad-webassembly/) on
Autocad porting their (30 year old) code base to the web via WASM.

------
hs86
I haven't listened to it yet but this very recent podcast episode has someone
from the Google Earth team on it:

[https://softwareengineeringdaily.com/2019/07/02/google-
earth...](https://softwareengineeringdaily.com/2019/07/02/google-earth-
webassembly-with-jordon-mears/)

------
aloer
I am confused about the multi-threading support in chrome. The article links
to [https://medium.com/google-earth/performance-of-web-
assembly-...](https://medium.com/google-earth/performance-of-web-assembly-a-
thread-on-threading-54f62fd50cf7) where they mention that chrome 74 added
support for threading. Reading the 74 release notes I can't find anything

[https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer) says that
SharedArrayBuffer was readded in chrome (behind a flag?) in v67, not 74. Is
that the same? Is SharedArrayBuffer equivalent to the support for multi-
threading or were other parts disabled due to spectre – or not yet implemented
in 2018?

This whole wasm/threading/spectre mitigation situation is difficult to follow

What is the state of this in July 2019. Do you know about a benchmark/good
example project that gives a good overview of what's currently possible?

context: I want to build a tile based view (tiles in x/y dimensions + zoom
levels). The content of the tiles is loaded from server (shapes mostly) and
rendered into tile images client side. I also want the same tiles prerendered
as identical images on the server.

For this I have a feeling that something like skia is the way to go. Skia can
be used via wasm bindings. How I would fetch the shapes and render the tiles
(or fetch the prerendered ones) transparently and then where to render the
tiles into, that is what I am trying to figure out. It feels like
multithreading could be very useful here. Right now only chrome appears to
support OffscreenCanvas (which can be accessed from webworkers), hence the
idea of using skia directly and possibly going a level higher to write
whatever kind of multithreaded render logic in rust and run it with wasm and a
single "canvas output". Whether skia is the right choice here or not is also
something I have yet to figure out

The ultimate goal is quick startup (prerendered tiles) while simultaneously
high performance when updating the entire view (=multiple tiles in parallel).
This is mostly a learning project for me

~~~
ehsankia
According to their docs [0], it was added in Chrome 70 behind a flag/origin
trial. I'm guessing that 74 is when the flag got turned to ON by default?
Here's the change which was back in February [1], so I think that's correct.

[0] [https://developers.google.com/web/updates/2018/10/wasm-
threa...](https://developers.google.com/web/updates/2018/10/wasm-threads)

[1] [https://chromium-
review.googlesource.com/c/chromium/src/+/14...](https://chromium-
review.googlesource.com/c/chromium/src/+/1487808)

------
neilv
I'll be interested to see whether they support this for practical use, whether
they provide programmability as much as the original, and how well they get it
to work under WASM.

The original Google Earth Plugin worked well on even Core Duo laptops with
very modest GPUs. I used it to do a technical Web front-end project that
pushed the limits of the Plugin. At the time, there was no other viable way to
do what was needed (with the requirement that it run in particular Web
browsers, as part of a larger Web system).

In my project, I did have to do a cute little multi-step camera movement at
the start of an interactive animation, to keep the Plugin from culling one of
the objects I'd added to the scene. I still wonder how many people using that
thought the camera movement was just zooming around for gee-whiz effect, or
for spatial context, rather out of necessity that the core functionality work
at all.

------
zbrozek
I wasn't given the option to run it with Firefox, and was prompted to install
Chrome instead. So it's hard to say it was ported to browsers (plural) as
opposed to browser (singular).

~~~
ehsankia
Make sure you use the right link. You have to click on the "beta preview" [0]
url, not the "Earth for Web" which takes you to the old NaCl implementation.
This should work on Firefox.

[0] [https://g.co/earth/beta](https://g.co/earth/beta)

------
cpeterso
If you're interested in mapping technology and the history of Google Maps
(Keyhole) in particular, check out Bill Kilday's book "Never Lost Again: The
Google Mapping Revolution That Sparked New Industries and Augmented Our
Reality". Kilday was a founder at Keyhole, the startup acquired by Google to
become Google Earth.

[https://www.amazon.com/dp/0062673041](https://www.amazon.com/dp/0062673041)

------
landcoctos
My favorite part of Google Earth is viewing the satellite imaginary history.
Does the web client support this?

~~~
Rebelgecko
Doesn't look like it. Considering that's the main reason I fire up the desktop
version of Earth, it's an unfortunate omission

~~~
iggldiggl
And conversely, historic _Street View_ images are only accessible through
Maps, but not desktop Google Earth.

------
underbluewaters
Beautiful. I'd love to see something along the lines of the old plugin-based
Google Earth API made available for this. I used to run an ocean conservation
planning application using that API but had to migrate to 2d maps. There has
been a very long gap since the plugin deprecation and the release of the
3d-view in Google Maps where there has been no good 3d API offered by Google.
I've been thinking "in the next 6 months they will probably release maps api
v4" for about 3 years now...

~~~
Stratoscope
If they do make an API, it won't have very many of the features from the
plugin's API. The plugin was based on the full-featured desktop version of
Earth, not this limited web-based version.

------
snek
Interestingly, they've been publicly working on this for over a year, but only
in the last few weeks did they remove the "only run in chrome" check.

------
LeonM
I just tried it on a modern machine (6-core i7, 32GB ram, GTX1050) on latest
Chrome for windows, and the fly-by animations were still not smooth.

I'm disappointed by that, but I guess the desktop app also never was smooth to
begin with.

------
landcoctos
Doesn't work on Firefox 67.0.4 64bit.

~~~
Ajedi32
That's only for the old NaCl version. The WASM version works in Firefox just
fine (though without multi-threading, as Firefox currently doesn't support
SharedArrayBuffer):
[https://earth.google.com/web/?beta=1](https://earth.google.com/web/?beta=1)

~~~
timvisee
Good to see a Google Earth Web instance is finally working in Firefox. Works
for me as well, in Firefox 69.

------
microcolonel
Seems dramatically slower than the satellite view in Google Maps. I guess this
is for people who have Google Earth based GIS stuff they want to keep using.

Is there some reason why WebGL applications never seem to make proper use of
my VRAM? Most of the data in these views are persistent, but they keep loading
them over and over again even though I have 16GiB of VRAM. I'm guessing WebGL
doesn't expose queries for that, so the applications play it safe?

~~~
kevingadd
Most browsers have a single gpu sandbox for all tabs, so image resources and
buffer data have to get rpc'd over and there's no realistic way to measure
resource limits let alone efficiently utilize all your vram. The browser might
have helpful internal limits like 512mb vram per tab, for all we know.

