91–100 of 107 posts
Earlier quoted context omitted.
Agree! They could have cached way more of this. A pre-rendered video would have had the same effect. A fun and impressive thing to build for sure, but its value isn't worth its complexity.
You can’t interact with a video.
Alt title: how we made yet another population density map, but this time using all of your CPU.
Earlier quoted context omitted.
> failIfMajorPerformanceCaveat This sounded like a joke, but I wasn't 100% sure. It's a real thing (code from Stack Overflow): const context = canvas.getContext("webgl", { failIfMajorPerformanceCaveat: true, }); Pretty neat.
I thought it was a joke too. What an awful flag all around: * Woefully ambiguous and underspecified - what is "major"? A 12 FPS drop compared to desktop? Below 30 FPS? Frame jitter outside a certain standard deviation? It will depend on the app (fast-paced frame-perfect game vs. "well I just want the animation to be smooth" necessarily have different requirements for performance), but this flag leaves it up to the br…
I hate the name too, but the flag was a necessary compromise to get past an impasse.
The problem at the time was that fullscreen WebGL in Firefox was an absolutely terrible experience on some machines, because they did a readback of the full framebuffer from the GPU to the CPU every frame. This didn't just make that tab slow, or even just the whole browser. It actually bogged down the entire computer. It made the mouse pointer skip. It was beyond unacceptable.
My preferred solution was that Firefox should disable WebGL on these machines. But the Firefox team did not want to do that, because it sort of worked OK as long as the canvas was only a small fraction of the screen. They also didn't want to expose any way of specifically detecting or disallowing readbacks. But no fullscreen WebGL application could be launched to a wide audience when a significant fraction of users would have their entire computer bog down and mouse pointer start skipping just loading the page.
So why couldn't you "just" detect that the framerate was low and turn off WebGL yourself? The problem with that is the first few frames at page load time are often slow for various reasons, some GPU related and some not. You have to render frames for a couple of seconds before you can reliably measure the steady state performance, and during that time the user's mouse pointer is skipping and they're already having a really bad time. If you then decide to disable WebGL, all that loading time and bandwidth was wasted and you have to start again loading your fallback content. So yeah you can measure performance but it doesn't solve the problem. Users still have a bad time.
As for the name, it was suggested (perhaps jokingly) by a Mozilla engineer and I decided to go with it for the proposal because they were the ones that needed convincing, and I figured they were more likely to accept a name that they suggested themselves. Bikeshedding the name could easily have derailed the whole thing.
I still wish that Firefox had just disabled WebGL on those machines, or at least agreed to provide an explicit way to detect and/or disallow readbacks. Then we wouldn't have needed the vaguely specified compromise solution.
Looks a lot like the globe on Stripe's homepage: https://stripe.com They even had a post about it, too: https://stripe.com/blog/globe
Earlier quoted context omitted.
Using the timezone was Github's way of easily getting the right orientation of the globe for the viewer's location. In my case (and I'm guessing everyone in the southern hemisphere) that doesn't work.
Aren't most globes oriented that way for display though? They copied the normal angle used for physical globes so it's instantly recognizable I suspect.
Wow, hardware acceleration makes a big difference here. I'm on a recent top of the line macbook pro and it couldn't handle it without hardware acceleration turned on. I wonder if they can/should disable the feature if it's off?
I am curious, why do you have hardware acceleration turned off? To answer your question, the failIfMajorPerformanceCaveat flag allows sites to turn off their hardware accelerated features when hardware acceleration is off.
(Full disclosure: I ported a prototype version of my company's globe data viz in 2013 using Three.js - it's terrific! Those folks are the real heroes in this story.)
Earlier quoted context omitted.
That shouldn't matter for the timezone, though, no?
Using the timezone was Github's way of easily getting the right orientation of the globe for the viewer's location. In my case (and I'm guessing everyone in the southern hemisphere) that doesn't work.
Source: https://youtu.be/p-MGKz4qjJw
Earlier quoted context omitted.
Aren't most globes oriented that way for display though? They copied the normal angle used for physical globes so it's instantly recognizable I suspect.
Whoosh, that was his point entirely. Globes are Northern hemisphere biased because of the history of European colonialism.
Pretty clever using the timezone offset to approximate the user's location without using GeoIP. I hadn't noticed that but sure enough, my (approximate) location is in view first.
Clever but a bit lame given the fact that I guarantee your IP address is already analyzed from a bazillion angles (incl. GeoIP) way before it hits the frontend process. Not sure why they can't use that information.