Skip to content
This repository has been archived by the owner on Apr 10, 2018. It is now read-only.

Prerendered layer type: keep or kill #232

Closed
lbud opened this issue Jan 13, 2015 · 6 comments
Closed

Prerendered layer type: keep or kill #232

lbud opened this issue Jan 13, 2015 · 6 comments
Milestone

Comments

@lbud
Copy link
Contributor

lbud commented Jan 13, 2015

Let's talk about this.

@nickidlugash you rewrote outdoors with terrain-v2 — what are your thoughts on this?

@ansis @kkaefer I remember talking about the potential for prerendered layers to serve as sort of fallback layers in slow styles or renderers. Does this make sense at all/still seem like a possibility? For anything but blurred layers, they look pretty awful unless you draw them at really large raster sizes, which isn't an especially perf-friendly trick.

cc @jfirebaugh @mourner @tmcw @edenh

@ansis
Copy link
Contributor

ansis commented Jan 13, 2015

I remember talking about the potential for prerendered layers to serve as sort of fallback layers in slow styles or renderers. Does this make sense at all/still seem like a possibility?

No, I don't think so. It would be great if we could kill them by not needing blur, or by faking blur some other way.

@nickidlugash
Copy link
Contributor

@lbud the main reason I removed the pre-rendered layer from outdoors was because the blur only takes literal values, not functions/ramps, and having the same level of blurring on all zoom levels was overall worse than having no blur at all (normally it makes sense to increase blur as zoom level increases). With the old terrain (where, on top of GL overzooming, the polygons were not as detailed to begin with), the blurring helped a bit to hide the overly-simple polygons. In terrain v2, the polygons are more detailed so this is much less necessary.

Are we at all still thinking about implementing functions/ramps for layout properties? If we are, the ability to blur could potentially be useful. However, as @lbud mentioned, prerendered layers look pretty bad without a blur, so if we were transitioning from no blur to some blur, I'm guessing that the zoom levels with no blur will not look good.

I guess if someone was making a map that was very limited in zoom levels, then the current blur functionality could be useful, but personally I don't find it useful.

@mourner
Copy link
Member

mourner commented Jan 13, 2015

👍 for killing off prerendered layers and not worrying about blur, terrain-v2 looks good without it. Lets worry about performance instead.

@ljbade
Copy link

ljbade commented Jan 14, 2015

From discussion with @nickidlugash

I would like to test the performance of pre-rendered vs live rendered V2 on older Android devices that have a slower GPU to make sure they can run the new outdoors style fast enough.

I note that Google use pre-rendered terrain in the Android app.

@edenh
Copy link
Contributor

edenh commented Jan 21, 2015

👍 for killing. As data density improves for vector sources, the need for this is diminishing.

@jfirebaugh
Copy link
Contributor

Agreed. We'll remove this for v7.

jfirebaugh added a commit to mapbox/mapbox-gl-js that referenced this issue Jan 21, 2015
jfirebaugh added a commit to mapbox/mapbox-gl-test-suite that referenced this issue Jan 21, 2015
This is a prerendered layer property which will no longer
be supported.

mapbox/mapbox-gl-style-spec#232
jfirebaugh added a commit that referenced this issue Jan 21, 2015
This was referenced Jan 21, 2015
Merged
jfirebaugh added a commit to cutting-room-floor/mapbox-gl-style-lint that referenced this issue Jan 21, 2015
jfirebaugh added a commit to cutting-room-floor/mapbox-gl-style-lint that referenced this issue Jan 21, 2015
@jfirebaugh jfirebaugh modified the milestone: v7 Jan 22, 2015
jfirebaugh added a commit to mapbox/mapbox-gl-js that referenced this issue Jan 22, 2015
jfirebaugh added a commit to mapbox/mapbox-gl-native that referenced this issue Jan 22, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants