Google Earth Ported to Browsers with WebAssembly

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.

Original blog post by Google: https://blog.chromium.org/2019/06/webassembly-brings-google-...

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.

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...

I am confused about the multi-threading support in chrome. The article links to https://medium.com/google-earth/performance-of-web-assembly-... 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... 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

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.

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).

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

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

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...

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.

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.

Doesn't work on Firefox 67.0.4 64bit.

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?