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.
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).
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.
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.
What advantages does the desktop app have compared to the web app when planning hikes?
I have used the web version before to plan hikes, but would be interested in expanding my tool set.
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 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
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.
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).
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.
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.
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...
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.
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
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?
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.
