The WebGL version of Google Maps overdraws like crazy, which is why it’s slow. That depth buffer is your friend, folks! Use it!
-
Show this thread
-
Not sold on Google Maps’ use of signed distance fields for text either. It makes small text blurry, presumably because it’s downsampled. SDF only really helps magnification, which they don’t do much.
1 reply 0 retweets 8 likesShow this thread -
Almost every Google Maps shader has a discard in it. I don’t see why this is needed. Not that they’re getting much benefit from early Z anyway since they draw back to front :(
3 replies 0 retweets 8 likesShow this thread -
Replying to @pcwalton
Early Z is hard because map designers tend to want to make everything slightly transparent.
2 replies 0 retweets 2 likes -
Replying to @jfire
Well, it does things like draw a gray background over the Presidio, only to cover it with green later.
1 reply 0 retweets 0 likes -
Replying to @pcwalton
I can think of a number of (arguably) legitimate reasons to do this. We've considered it for Mapbox GL; see https://github.com/mapbox/mapbox-gl-js/issues/2074 … for details.
1 reply 0 retweets 0 likes -
Replying to @jfire
Hmm, when I removed early Z in Pathfinder my performance cratered on workloads like the tiger. For AA I ended up with a 2-pass implementation that fills all opaque interiors front to back and then, with early Z on, antialiases back to front.
2 replies 0 retweets 0 likes -
Replying to @pcwalton
Yeah, this is what mbgl does too. We haven't benchmarked removing early Z, but we have a number of z-indexing bugs that would be fixed by doing so.
1 reply 0 retweets 0 likes
Yeah, early Z is such a pain…there’s so much code in WebRender needed to make it work :( But at least in our experience it’s been very much worth it…
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.